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1.0  MANAGEMENT  OVERVIEW 


1 . 1  Background 

Inexpensive  hardware,  expensive  software,  large  complex  systems,  and  a 
multitude  of  other  influences  have  converged  very  recently  to  cause  some 
fairly  large  upheavals  in  the  area  of  developing  systems.  In  fact,  events 
are  happening  so  quickly  that  it  is  difficult  for  management  to  know  where, 
how  and  what  to  respond  to.  There  is,  however,  evidence  of  some  common¬ 
ality  in  the  reactions  that  are  taking  place  and  noticeable  trends  appear 
to  be  developing.  A  sufficient  number  of  large  complex  systems  have  been 
developed  or  have  been  attempted  to  be  developed,  in  which  significant 
problems  have  arisen  to  arouse  concern. 

One  very  significant  reaction  to  this  phenomena  is  that  of  DoD  who, 
in  turn,  reacted  with  various  directives.  These  directives  have  had 
major  influence  throughout  the  industry,  both  in  the  government  and  commer¬ 
cial  environments.  As  a  result,  RFP  requirements,  contractor  requirements, 
amount  and  types  of  customer  visibility,  contractor  qualifications,  systems 
development  models,  final  system  products,  and  methods  of  producing  systems 
are  experiencing  major  changes. 

Many  people  involved  in  large  systems  are  beginning  to  talk  to  each  other, 
realizing  that  their  problems  are  not  only  not  unique,  but  perhaps 
they  can  learn  from  each  other  in  attempting  to  address  the  more  serious 
issues  that  have  come  to  the  forefront.  For  example,  software  often 
does  not  satisfy  the  original  specifications.  The  basic  reason  for  this 
is  the  inadequate  techniques  that  are  used  for  specification— in  many  cases 
it  would  be  impossible  to  develop  a  correct  program  from  original  specifica¬ 
tions,  for  to  do  so  would  be  like  deriving  a  consistent  model  from  an 
inconsistent  theory. 

Our  experience  has  indicated  that  interface  problems  (i.e.,  data  and 
tiring  conflicts)  within  a  system,  between  systems,  and  between  various 
stages  of  system  development  account  for  the  majority  of  the  problems  involved 
in  the  construction  of  large  systems  [4],  These  interface  problems 


either  took  place  when  attempting  communication  or  resource  allocation 
(a  process  of  preparing  for  communication). 

As  a  result,  the  very  basis  of  the  methodology  of  Higher  Order  Software 
(HOS),  based  on  our  analysis  of  problems  relating  to  the  development 
of  large  systems,  e.g.,  Apollo,  Shuttle,  etc.  concerns  itself  with  the 
definitions  of  systems  so  as  to  cl imlnate  data  and  timing  conflicts. 

Mot  only  did  we  find  that  interface  problems  contributed  towards  making 
software  systems  unreliable,  but  they  also  increased  the  frequency  of  cost 
overruns  and  missed  deadlines,  for  such  conditions  usually  resulted  when 
integration  of  individually  completed  modules  was  attempted.  No  matter 
how  "structured"  and  correct  an  individual  module  may  be,  unless  the 
system  structure  is  consistent  and  complete,  a  project  will  undoubtably 
have  errors. 

Managers  are  beginning  to  realize  that  they,  themselves,  are  in  a  very 
enviable  position  to  do  something  about  helping  to  advance  the  technology 
of  developing  systems,  since  they,  and  only  they,  are  the  ones  who  have  been 
forced  to  lead  the  way.  Upon  observing  themselves  and  others,  they  have 
come  to  realize  that  certain  basic  concepts  such  as  understanding 
a  problem  before  solving  it  are  of  major  importance.  Towards  this  aim 
managers  are  recognizing  the  importance  of  communication  and  are  now 
concerning  themselves  with  finding  various  methods  to  better  define 
specifications  as  well  as  to  expedite  their  definitions  and  their  im¬ 
plementations.  As  a  result,  there  is  now  a  proliferation  of  "methodologies" 
which  brings  back  memories  of  the  proliferation  of  higher-order  languages 
in  the  sixties.  Within  this  environment,  certain  philosophies  are  be¬ 
ginning  to  be  more  commonly  accepted.  These  include  the  importance  of 
hierarchical  decomposition,  emphasis  on  front-end  system  design,  inte¬ 
gration  of  "modules"  within  a  development  phase  and  throughout  a  develop¬ 
ment  process,  and  the  emphasis  on  finding  or  developing  an  effective 
reauirements  or  specification  language. 


There  are  some  concerns,  however,  in  attempting  to  improve  current 
methods  of  developing  systems.  We  include  here  a  set  of  typica1  questions 
which  reflect  these  concerns,  and  answers  based  upon  our  own  experience. 

In  later  sections  of  this  report,  we  will  attempt  to  address  these  issues 
within  the  context  of  the  PLRS  project. 


Hi  ioc  +■  •?  r> r*  « 
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How  can  we  tell  if  a  methodology 
methodology  at  all? 


uii  1 1  woyi;  better  than  no 


Answer:  Compare  the  properties  of  the  methodology  with  those  used  in 

an  existing  development  with  respect  to  a  well  defined  set  of 
requirements  for  consistency  and  completeness. 


Question:  How  do  we  choose  between  one  methodology  and  another  methodology? 


Answer:  Compare  the  properties  of  the  two  methodologies  with  respect 

to  a  well  defined  set  of  requirements  for  consistency  and  com¬ 
pleteness. 


Question:  What  is  the  difference  between  using  a  methodology  and  using 
"smart"  people? 

Answer:  fhe  smartest  "erson,  by  definition,  would  apply  an 

effective  me*  jdology.  An  effective  methodology  would 
far  exceed  the  advantages  of  a  smart  person  applying  his 
techniques  in  an  ad  hoc  manner,  since  all  the  intricacies 
of  a  complex  system  are  by  its  nature  beyond  the  grasp  of 
one  human  being.  The  designs  of  all  smart  people  must 
be  integrated. 

Question:  How  do  we  use  a  methodology  without  impacting  deliverables 
of  an  on-going  project? 

Answer:  Choose  those  aspects  of  the  methodology  which  find  errors 

or  which  expedite  the  design  and  implementation  process. 


Question:  How  do  we  convince  management,  designers,  and  users  to 
use  different  approaches? 

Answer:  A  different  methodology  should  be  demonstrated  within  the 

environment  of  the  Deople  who  will  use  it. 


Question:  What  creativity  is  left  for  the  engineers  if  a  methodology 
has  constraints? 


Answer  An  effective  methodology  should  support  creative  designers 
and  not  constrain  them  from  producing  better  designs  but 
rather  constrain  them  from  producing  errors. 
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1.2  Existing  Methodologies 


Although  the  recently  founded  philosophical  goals  of  various  systems 
managers  are  important  ones,  there  exists  a  proliferation  of  problems 
in  the  attempt  to  reach  these  goals,  both  in  developing  a  new  methodology 
or  in  choosing  an  existing  methodology.  There  are,  of  course,  many 
methodologies  whose  intent  is  to  solve  various  aspects  of  the  problem 
of  developing  systems.  The  developers  of  these  methodologies  are  all  pro¬ 
ponents  of  reliable  systems  with  efficient  methods  for  developing  these 
systems.  And,  most  methodologies  advocate  many  philosophies  that  are  similar. 
For  example,  it  is  a  commonly  accepted  idea  that  it  is  beneficial  to  produce 
a  hierarchical  breakdown  of  a  given  design  in  order  to  provide  more 
manageable  pieces  to  work  with.  And,  there  are  variations  between  method¬ 
ologies.  Some  emphasize  a  concentration  on  data  flow  as  opposed  to 
functional  flow  [10],  [1  ],[3  ]  [12]*,  others  emphasize  documentation 
standards  [9]  [15];  others  emphasize  graphical  notations  [13];  and 
still  others  emphasize  semantic  representation  [17]. 

There  are  certainly  positive  aspects  in  many  of  these  methodologies  end, 
in  particular,  in  what  they  are  trying  to  obtain.  To  be  effective, 
however,  a  methodology  should  have  techniques  and  rules  for  the  purpose  of 
defining  systems  which  are  consistent  and  complete.  But  these  techniques  and 
rules  are  useful  only  if  they  are  within  themselves  consistent  and  complete, 
both  with  respect  to  each  other  and  to  the  systems  to  which  they  are 
being  applied. 

7c:  rten  the  same  problems  exist  in  the  development  of  methodologies 
as  exist  in  the  problems  the  methodologies  are  intended  to  address. 

That  is,  there  are  often  inconsistencies  within  a  methodology.  In  addition, 
improvements  to  a  methodology  are  often  ad  hoc  and  modifications  to  a 
methodology  to  fix  or  enhance  that  methodology  are  made  to  already 
existing  modifications. 

Likewise,  in  the  attempt  to  select  an  existing  methodology,  there  is  always 
a  risk  of  comparing  (1)  techniques  addressing  very  different  problems, 

(2)  techniques  intending  to  address  a  problem,  but  not  effectively  ad¬ 
dressing  it  at  all,  (3)  techniques  with  respect  to  non-existant  or  ill- 
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defined  requirements,  (4)  the  "syntax"  of  methodologies  instead  of  the 
"semantics"  of  methodologies,  (5)  techniques,  based  on  unfamiliar  para¬ 
digms  with  preconceived  notions,  (6)  techniques  addressing  the  wrong 
problems  or  those  which  are  "in  the  noise,"  and  (7)  techniques  with  re¬ 
spect  to  completion  or  amount  of  use  rather  than  with  respect  to  the 
problems  they  are  solving. 

1 . 3  Requirements  for  an  Effective  Methodology 

Most  importantly,  the  time  has  come  when  one  is  forced  by  large  systems 
to  look  closely  at  properties  of  systems.  They  are  more  basic  than  one 
cares  to  admit.  If  this  fact  is  ignored,  there  is  a  risk  of  responding  to 
only  symptoms  and  investing  a  great  deal  of  effort  based  on  preconceived 
notions  and  misquided  misconceptions. 

In  choosing  requirements  for  a  methodology,  issues  such  as  how  people  think, 
learn,  communicate,  and  resource  allocate  need  to  be  addressed.  These 
issues  are  not  unlike  those  of  "older,"  more  established  fields,  like 
philosophy  or  mathematics,  and  more  recently,  linguistics.  But  when 
working  with  large  systems,  there  is  the  advantage  of  more  visibility  into 
some  basic  issues  than  was  ever  provided  before.  What  is  suggested  is  not 
only  a  whole  new  set  of  paradigms  for  developing  systems,  but  more  importantly, 
a  whole  new  attitude  on  accepting  that  fact.  It  is  within  the  framework 
of  such  a  set  of  paradigms  that  proper  research  requirements  for  method¬ 
ologies  ,  including  methods  for  specifying  specification  techniques  before 
specifying  systems,  can  be  determined. 

The  first  step,  then,  is  to  define  more  explicitly  what  it  is  that 
needs  to  be  solved  and  then  to  define  more  explicitly  how  to  respond 
to  this  need.  To  be  effective,  a  methodology  should  have  the  mechanisms 
to  consistently  and  completely: 

Define  an  object  and  its  relationships  formally.  That  is,  every 
system  in  the  environment  of  an  object  system  (people,  hardware, 
tools,  software)  understand  a  definition  of  an  object  and  its 
relationships  the  same  way. 


Provide  for  modularity.  That  is,  any  change  should  be  able  to  be 
made  locally  (with  respect  to  levels  and  layers  of  development  [5]), 
and  if  a  change  is  made,  the  result  of  that  change  should  be  able 
to  be  traced  throughout  both  the  system  within  which  that 
change  resides  and  throughout  other  systems  within  that  system's 
environment. 

Provide  a  set  of  primitive  standard  mechanisms  which  are  used 
both  for  defining  and  verifying  a  system  in  the  form  of  a  hier- 
archy. 

Provide  for  an  evolving  set  of  more  powerful  (with  respect  to 
simplicity  and  abstraction)  mechanisms  based  on  the  standard 
set  of  primitive  mechanisms. 

Allow  system  engineers  to  communicate  in  a  language  (with  common 
semantic  primitives  and  a  dialect  of  their  choice)  which  is  ex¬ 
tensible,  flexible,  and  familiar  and  which  serves  as  a  "library" 
of  common  data  and  structure  mechanisms. 

Provide  for  a  development  model  which  includes  a  set  of  defini¬ 
tions,  tools,  and  techniques  which  support  a  given  system  develop¬ 
ment  process. 


1 .4  How  HOS  Responds  to  the  Requirements  for  an  Effective  Methodology 


We  will  discuss  HOS  in  terms  of  the  requirements  we  have  set  forth  for 
methodologies  in  general,  before  discussing  the  application  of  HOS  within 
the  environment  of  the  PLRS  project. 


FORMAL 


HOS  systems*  are  formal  in  that  the  relationships  of  all  objects  are  ex¬ 
plicitly  defined  in  terms  of  completeness  of  control.  That  is,  all  HOS 
systems  always  have  the  same  properties  with  respect  to  control  of  interfaces 
as  a  result  of  standard  and  well  understood  ways  of  defining  interfaces. 

Thus,  everyone  defining  a  module,  using  HOS,  must  follow  the  same  rules  as 
everyone  else  in  constructing  the  structure  of  that  module.  The  control  of 
every  object  in  a  system  is  determined  by  adherence  to  six  axioms  [c.f.  Appendix  I]. 


by  a  system  we  mean  an  assemblage  of  objects  united  by  some  form  of 
regular  interaction  or  interdependence,  where  an  object  is  an  existence 
of  something. 
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These  axioms  are,  in  essence,  a  consistent  set  of  rules  that  determine  a 
means  for  defining  systems  that  are  consistent,  complete  and  not  redundant. 
These  rules  determine  a  means  for  defining  invocation  of  functions,  input, 
output,  input  access  rights,  output  access  rights,  error  detection  and 
recovery,  and  ordering  of  functions.  When  these  rules  are  applied,  there 
is  no  room  for  ambiguity  with  respect  to  control.  That  is,  everything  must 
be  controlled  and  every  object  has  a  unique  controller.  All  objects  in  an 
HOS  system  can  be  described  in  terms  of  control  structures,  derived  from 
the  six  axioms,  that  relate  members  of  algebraicially  defined  data  types 
or  functionally  defined  data  whose  components  are  algebraically  defined. 

MODULAR 


Systems  defined  in  HOS  satisfy  the  requirements  we  have  set  forth  for 
modularity.  Control,  or  the  chain  of  command,  can  be  traced  directly  on 
an  HOS  control  map.  Function  flow  (including  both  input  and  output) 
can  be  traced  directly  on  an  HOS  control  map.  In  addition,  the  nature  of 
HOS  systems  is  such  that  the  mechanisms  of  defining  systems  as  well  as 
the  systems  themselves,  behave  as  if  they  are  "instructions,"  e.g., 
a  given  control  structure  has  no  knowledge  about  a  higher-level  control 
strucutre.  With  these  properties,  changes  can  be  traced  directly  and 
changes  can  be  made  locally.  Systems  defined  in  HOS  display  certain  other 
distinctive  properties.  For  example,  HOS  systems  have  been  shown  to  be 
secure  systems  [2]  and  the  single  reference,  single  assignment  properties 
of  HOS  systems  provide  an  interesting  set  of  resource  allocation 
alternatives. 

PRIMITIVE  STANDARD  MECHANISMS 


Three  primitive  control  structures,  derived  from  the  axioms  [4]  pro¬ 
vide  rules  for  the  definition  of  dependent  functions  (e.g.,  sequential 
processing),  independent  functions  (e.g.,  parallel  processing),  and 
selection  of  functions  (e.g.,  reconfiguration).  From  a  combination  of 
primitives,  more  abstract  control  structures  can  be  found  (e.g.,  recursive 
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functions).  A  complete  design  is  one  which  has  been  hierarchically 
decomposed  until  all  terminal  nodes  of  a  control  structure  represent 
primitive  operations  on  data  types. 

Thus  AXES,  the  specification  language  based  on  HOS,  is  able  to  have  a 
common  set  of  specification  primitives  (i.e.,  a  common  specification 
"machine").  As  a  result  it  is  possible  to  have  common  tools,  such  as  an 
analyzer  to  check  for  correct  interfaces  (i.e.,  completeness,  consistency, 
and  elimination  of  redundancy)  and  a  resource  allocation  tool  to  prepare 
a  specification  for  a  particular  machine  environment  (c.f.  Appendix  II). 

EVOLVING  MECHANISMS 


Although  a  system  can  be  defined  directly  with  AXES,  a  more  powerful  use 
of  AXES  can  be  made  by  defining  systems  which  are  themselves  mechanisms  for 
defining  systems.  Thus,  we  can  define  a  set  of  specification  "macros" 
which  collectively  could  form  a  "language"  (or  management  standards) 
for  defining  a  particular  system  or  family  of  systems.  Each  new  system 
user  is  able  to  use  a  subset  of  already  defined  statements  in  an  AXES- 
based  library  or  add  new  statements  since  the  AXES  language  system  is 
extensible  both  with  respect  to  structure  and  data  definitions. 

FAMILIAR  DIALECTS 


AXES  provides  a  user  with  the  capability  of  defining  any  syntax  desired  for 
a  control  structure  or  data  type.  Thus,  for  example,  a  communications 
project  is  able  to  have  its  own  set  of  specification  statements  to  use 
as  a  means  of  standardizing  and  an  avionics  project  is  able  to  have  its 
own  set  of  statements.  But,  both  are  able  to  communicate  in  common  at 
the  level  of  the  primitive  specification  machine  to  which  these  statements 
can  be  reduced  to  their  primitive  form. 


DEVELOPMENT  MODEL 


AXES  provides  the  mechanisms  to  define  a  development  model  as  a  system  and 
to  define  the  management  of  a  system  development  model,  which  uses  that 
development  model,  as  a  system.  Within  the  context  of  a  complete 
development  provess,  HOS  provides  a  means  to  define  management  standards, 
definitions,  milestones,  disciplines,  phases,  and  tools  and  techniques 
and  the  relationships  between  all  the  various  ccmnonents  within  a  develop¬ 
ment  process. 


Previous  Experiences  with  the  Application  of  HOS 


Once  the  foundations  of  HOS  were  formulated,  it  was  then  necessary  to  apply 
the  methodology  to  some  actual  applications  in  order  to  demonstrate  its 
effectiveness. 


Initially,  we  chose  the  Apollo  Guidance  Computer  (AGC)  operating  system, 
an  application  familiar  to  us  [8  1.  Unfortunately,  we  had  a  great  deal  of 
difficulty  reconstructing  the  pieces.  This  was  due  mostly  to  the  fact 
that  the  AGC  operating  system  was  poorly  documented.  Our  only  solution 
for  completely  understanding  the  system  (which  included  our  own  design 
and  our  own  coding)  was  to  go  back  and  pour  over  the  original  code, 
which  was  very  clever  and  difficult  to  understand.  When  we  began  this 
effort,  we  thought  there  was  little  in  the  AGC  operating  system  we  could 
improve  upon..  This  attitude  was  partly  as  a  result  of  the  fact  that 
no  errors  were  found  for  several  years  within  the  operating  system  (OS) 
itself.  However,  when  we  attempted  to  specify  the  operating  system  with 
HOS,  we  discovered  that  many  of  the  development  errors  which  occurred  in 
the  application  programs,  using  the  OS,  would  not  have  occurred  if  the 
AGC  OS  had  certain  other  inherent  properties.  For,  although  the  AGC  OS 
had  properties  of  hidden  data,  it  did  not  have  properties  of  hidden  timing. 
From  this  effort,  we  therefore  determined  that  HOS  was  very  helpful 
in  cemonstrating  more  reliable  design  goals  with  respect  to  interfaces 
between  application  programs  and  the  systems  software  which  executes 
these  programs. 
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We  then  selected  an  application  to  demonstrate  another  aspect  of  our 
techniques.  Here  we  extracted  a  problem  definition  from  an  existing 
description  of  a  typical  orbit/altitude  spacecraft  problem  to  demonstrate 
the  ability  of  our  technique  as  a  guide  to  design  and  verification  [6  ]. 
Although  this  problem  was  relatively  small,  we  were  able  to  use  HOS  in 
determining  what  questions  to  ask  in  understanding  the  problem.  In 
addition,  we  provided  alternative  designs  at  the  level  of  the  user  inter¬ 
face,  so  that  the  human  user  functions  were  less  error  prone.  Many 
of  the  interfaces  existed  only  in  the  minds  (as  is  characteristic  of 
most  projects  today)  of  a  small  collection  of  experts  who  had  been  involved 
in  the  original  project.  Our  emphasis  was  to  integrate  and  fill  in, 
where  necessary,  interfaces  that  were  missing  in  the  specification  document. 

We  have  just  completed  the  definition  of  a  multilanguage  structured 
flowcharter  in  AXES  which  we  are  implementing  in  PASCAL  [7  ].  The 
programmers  who  are  implementing  the  flowcharter  are  determining  the  design 
of  the  code  by  using  the  control  maps  as  a  guide  to  design.  From  the 
control  maps,  the  programmers  are  able  to  directly  determine  the 
"whats"  with  respect  to  implementation  and  the  alternatives  with  respect 
to  the  "hows"  of  implementation. 

The  above  three  tasks  contributed  in  the  determination  of  the  effective¬ 
ness  of  HOS  with  respect  to  real  world  applications.  We  had  not,  however, 
attempted  to  apply  HOS  to  an  ongoing  project,  or  to  a  project  whose 
application  was  quite  unfamiliar  to  us.  Such  an  opportunity  was  provided  to 
us  by  PLRS. 

1 . 6  An  Overview  of  the  PLRS  Project 

Our  charter,  with  respect  to  PLRS,  was  to  select  the  most  complex  module, 
specify  that  module  in  terms  of  HOS,  and  demonstrate  the  advantages  of 
applying  an  effective  methodology  (in  particular,  HOS).  We  did  just  that. 
But,  there  were  several  additional  interesting  results  and  observations 
that  resulted  from  this  effort.  A  detailed  description  of  this  effort 
is  contained  in  the  remaining  sections  of  this  report.  The  following 
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summarizes  the  PLRS  effort  and  the  key  results  of  this  effort. 


•  The  most  complex  module  of  the  network  manager  has  been  specified 
with  an  HOS  control  map. 

•  Identification  of  commonality  between  modules  was  shown. 


•  A  description  is  provided  to  show  how  we  defined  the  network  manager 
control  map. 

•  Differences  between  the  control  map  and  the  information  provided 
in  the  PPS  have  been  determined. 

•  Advantages  of  control  map  techniques  with  respect  to  management, 
design,  implementation,  verification,  and  documentation  have  been 
determined  for  PLRS. 

•  Sixteen  categories  of  questionable  areas  such  as  unanswered 
questions,  inconsistencies,  incompleteness,  and  redundancies 
have  been  determined. 

•  Some  suggested  methods  of  specifying  the  control  map  with 

AXES  statements' are  shown.  A  comparison  of  the  PPS  with  an  al¬ 
ternative  method  using  AXES  is  provided. 

•  Specific  recommendations  with  respect  to  the  network  manager 
have  been  determined. 

•  Standards  (common  structures  and  data  types)  have  been  defined 
for  the  network  manager  with  AXES.  These  standards 

can  be  used  not  only  for  other  PLRS  modules  but  for  a  family  of 
communication  systems  as  well. 

•  A  section  of  the  PPS  was  rewritten  to  incorporate  HOS  techniques 
in  order  that  a  comparison  could  be  made  on  a  one-for-one  basis 
between  the  existing  PPS  and  a  PPS  using  AXES,  the  specification 
language  of  HOS. 

9  General  recommendations  with  respect  to  the  PLRS  project  have  been 
determined. 

•  General  recommendations  with  respect  to  further  efforts  have  been 
determined. 


1.7  PLRS:  Lessons  Learned 


PLRS  is  the  first  effort  in  which  we  attempted  to  use  HOS  on  an  on¬ 
going  project.  Not  only  was  our  aim  to  demonstrate  the  effectiveness 
of  HOS,  but  also  to  perform  this  task  without  impacting  schedules  or  de¬ 
liverables  of  the  PLRS  project.  In  this  process,  however,  we  determined 
that  the  use  of  an  effective  methodology  can  not  only  benefit  a  new  pro¬ 
ject,  but  it  can  also  benefit  an  ongoing  project  which  already  employs  a 
different  methodology.  Such  benefits,  some  of  which  are  described  below, 
fall  into  two  main  categories:  those  which  make  the  system  more  reliable 
and  those  which  help  to  accelerate  the  development  process. 

Acceleration  of  the  Learning  Process 

The  people  who  performed  the  HOS/PLRS  task  were  unfamiliar  with  the  PLRS 
project.  This  has  its  advantages  and  its  disadvantages.  The  disadvantages 
may  appear  obvious,  for  it  is  always  helpful  to  understand  as  much  as 
possible  about  an  application  before  working  on  it. 

But,  because  we  were  unfamiliar  with  the  PLRS  effort,  we  were  able  to  take 
advantage  of  such  a  fact  in  order  to  test  HOS  as  a  learning  technique. 

Our  method  of  understanding  the  network  manager  was  to  first  attempt  to 
construct  a  control  map  and  by  doing  so,  we  were  able  to  determine  existing 
functions  and  their  relationships.  This  process  not  only  provided  us  with  an 
accelerated  means  of  asking  the  questions  that  should  be  asked  to  construct 
the  definition  of  the  network  manager,  but  it  also  became  clear  that  this 
was  a  technique  for  prompting  questions  that  otherwise  may  never  have  been 
asked.  For,  during  this  process,  we  found  that  there  were  areas  in  the  PLRS 
documentation  which  were  not  clear  enough,  missing,  inconsistent,  redundant, 
or  not  integrated  with  other  areas. 

The  fact  that  we  were  able  to  use  the  HOS  control  map  technique  as  an 
accelerated  learning  process  for  ourselves  suggested  to  us  that  this 
same  technique  could  be  used  as  a  learning  tool  ,  for  example,  for  those 
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new  people  coming  aboard  a  project,  a  manager  learning  about  the  work 
of  the  people  in  his  project,  designers  learning  about  each  others  modules  in 
the  same  project,  implementers  learning  the  specification  they  are  imple¬ 
menting,  and  users,  such  as  maintenance  people,  learning  the  system  they 
are  using  or  changing. 


Acceleration  of  the  Specification  Process 

Although  the  specification  of  the  network  manager  (the  particular  PLRS 
module  chosen  for  demonstration)  was,  for  all  practical  purposes,  thought 
to  be  complete,  it  was  necessary  for  us  to  design  more  explicitly  function 
definitions,  including  data  definitions,  as  well  as  the  integration  of 
these  functions.  In  the  process  of  constructing  the  various  components  of 
the  network  manager,  the  HOS  control  map  technique  was  quite  effective  in 
expediting  design  processes.  By  using  the  control  map  technique  we  were 
able  to  determine: 


«  Types  of  design  tradeoffs 

•  Correctness  of  design  decisions  with  respect  to  consistency, 
completeness,  and  lack  of  redundancy  (i.e.,  verification  before 
the  fact). 

•  Common  use  of  specification  modules  (data  types  and  structures) 

•  More  powerful  and  simpler  ways  of  conveying  specifications 

•  When  each  specification  module  is  completed 

•  How  to  safely  integrate  all  the  modules  in  the  system 

•  Common  rules  (or  management  standards)  of  communication  between 
modules  in  the  system 

o  Methods  of  defining  the  system  so  that  changes  could  be  made 
safely  and  the  effects  of  those  changes  traceable  within  the 
design  and  during  the  design  process. 


It  was  clear  in  the  PLRS  effort  that  the  HOS  methodology  not  only 
supported  a  designer  in  providing  designs  more  quickly,  but  it  also  helped 
to  point  out  things  he  might  have  forgotton  about  completely. 


Verification  and  Validation  Aid 


In  the  process  of  analyzing  the  network  manager  and  redefining  its  most 
complex  modules  with  HOS,  we  were  able  to  show  the  effectiveness  of  HOS 
as  a  verification  and  validation  aid.  Several  errors  were  discovered 
by  the  two  step  process  of  (1)  formally  defining  the  data  types  that 
were  used  and  (2)  formally  defining  the  structure  (or  organization)  of 
the  network  manager.  These  errors  were  found  by  checking  existing  spec¬ 
ifications  from  the  standpoint  of  interface  reliability  using  control 
structure  and  data  type  mechanisms.  All  in  all,  sixteen  categories  of 
questionable  areas  were  found.  If  problematic  areas  are  detected  early 
as  illustrated  by  the  application  of  the  control  technique  to  PLRS, 
later  development  phases  can  benefit,  since  problem  are  not  only  able 
to  be  detected  earlier  or  prevented  before  the  fact,  but  these  problems 
will  not  surface  later  or  propagate  into  worse  problems. 

Establishment  of  Design  Goals 

In  the  process  of  understanding  the  network  manager,  it  would  have  been 
helpful  if  the  PPS  had  concerned  itself  more  with  the  definition  of  how 
the  specified  functions  related  to  each  other  (particularly  at  the  top 
level).  The  control  map  technique  forced  us  to  consider  integration  of 
the  functions  of  the  network  manager  from  the  very  beginning.  Such  a 
design  philosophy,  if  applied,  not  only  aids  in  understanding  a  design 
but  eliminates  integration  problems  that  would  subsequently  show  up  in 
later  development  stages,  such  as  the  PDS.  Thus  if  the  PPS  was  inte¬ 
grated  the  PDS  could  be  an  evolving  document  in  stead  of  a  "redo"  of  a 
more  detailed  PPS. 

Enhancement  of  Existing  Techniques 

Vie  were  able  to  indicate  certain  problem  areas  or  demonstrate  ways  of 
making  certain  improvements  to  the  PPS  without  impacting  schedules  or 
milestones.  Advantages  can  be  taken  of  our  findings  such  as  I/O  com- 

oatability  and  understandina  the  data  involved,  within  the  environment 
of  previously  existing  techniques  other  than  our  own. 


Management  Visibility 

During  this  project,  we  were  able  to  determine  a  "feel"  for  the  state  or 
health  of  the  specifications  of  PLRS,  in  general,  by  viewing  a  section  of 
PLRS.  That  is,  we  were  able  to  get  a  better  idea  of  the  types  of  interface 
problems  that  needed  to  be  resolved  before  the  specification  could  be 
successfully  implemented.  We  were  also  able  to  determine  what  steps 
would  be  necessary  before  the  specification  could  be  called  a  complete 
specification.  And  we  were  able  to  determine  certain  recommendations 
which  we  thought  would  be  quite  helpful  in  providing  a  more  reliable 
specification  more  efficiently  in  the  future. 


1 .8  Recommendations  for  PLRS  and  Future  Efforts 

Put  simply,  the  most  urgent  need  on  any  large  system  development  process 
is  that  of  standardization.  Ultimately,  aside  from  being  effective, 
standards  should  be  consistent  with  each  other,  not  redundant,  and  com¬ 
plete. 

Some  standardization,  if  it  is  effective,  is  certainly  better  than  none 
at  all.  But,  if  a  project  is  already  in  development,  it  is  not  usually 
possible  to  apply  an  ideal  and  complete  set  of  standards.  But  it  is 
possible  to  incrementally  begin  to  use  those  standards  which  would  enhance 
the  development  process  either  by  finding  errors  or  by  accelerating  remain¬ 
ing  phases  of  development.  We  did  this  on  Apollo.  For  example,  we  dis¬ 
covered  that  many  interface  errors  took  place  in  the  implementation  phase 
when  programmers  would  use  instructions  like  "GOTO  +3."  Errors  would  creep 
in  when  someone  would  come  along,  often  the  same  programmer,  and  inad¬ 
vertantly  insert  a  card  between  the  GOTO  instruction  and  the  location  it 
should  have  gone  to.  Once  we  discovered  the  amount  of  errors  which  resulted 
from  this  use  of  our  language,  we  enforced  by  standardization  the  use  of 
instuctions  such  as  "GOTO  A"  rather  than  "GOTO  +3."  As  a  result,  errors 
which  fit  into  the  above  category  never  happened  again.  This  type  of 
incremental  enhancement  to  our  own  methods  was  very  effective  on  an  ongoing 
project.  The  same  sort  of  introduction  of  standards  could  take  place  on 
PLRS  and  other  projects,  for  PLRS  is  not  unique  in  requiring  certain  en¬ 
hancements.  If  anything,  the  PLRS  documentation  is  quite  representative  of 
docu -entation  we  have  reviewed  from  several  projects;  for  we  all  suffer 


15 


from  the  syndrome  of  hurrying  to  get  the  design  process  done  because  of 
deliverables  which  appear  impossible  to  meet,  especially  if  we  pause  to  come 
up  with  standards.  But  hindsight  and  recent  experiences  of  our  own  and 
others  have  demonstrated  that  in  the  end  it  pays  to  organize  first  and 
build  later,  particularly  when  we  are  involved  in  the  development  of  large 
and  complex  systems. 


There  are  several  standards  that  we  recommend  be  used  in  the  PLRS  or  a 
PLRS-like  environment: 

•  Definition  of  design  goals  -  e.g.  ,•  definition  of  interfaces 
should  be  made  in  the  PPS  phase,  i.e.,  integrate  from  the  beginning. 

•  Rules  for  design  and  verification  -  specifications  should  be 
defined  hierarchical ly  and  rules  (e.g.,  those  that  accompany  the  control 
map)  should  be  followed  with  respect  to  how  one  level  in  a  heirarchy 
relates  to  the  function  directly  above  it.  These  rules  should  include 
ways  of  defining  the  invocation  of  a  set  of  functions,  input  and  output 
flow,  input  access  rights,  output  access  rights,  error  detection  and  re¬ 
covery,  and  ordering. 

•  Interface  Specification  Document  -  for  every  system  a 
standard  dictionary  (or  library)  should  exist  which  provides  common 
meanings,  ways  of  saying  things,  ways  of  doing  things,  mechanisms  for 
defining  a  system,  system  modules,  and  support  tools  and  techniques. 

For  PLRS,  we  would  have  found  it  extremely  useful,  and  believe  the  PLRS 
people  could  benefit  even  more,  if  an  evolving  dictionary  were  introduced 
which  included  a  set  of 

-  definitions  of  terms 

-  formally  defined  data  types 

--formally  defined  control  structures 

-  system  functions 

•  User  Manual  -  a  user  manual  should  be  provided  which  contains 
checklists  and  explains  (1)  how  users  interpret  the  standards  in  the  inter¬ 
face  specification  document,  (2)  how  designers  design  modules  to  add  to 
the  "iibrary"  of  the  interface  specification  document;  and  (3)  how  managers 
define  new  standards  for  system  development  which  in  turn  can  be  converted 
to  modules,  by  the  designers,  to  incorporate  into  the  interface  specifi-:. . 
cation  document. 

•  User  Guide  to  Implementation  -  If  specifications  contain 
certain  consistent  properties,  one  can  take  advantage  of  these  properties 
by  understanding  their  consequences  with  respect  to  implementation.  Given, 
that  there  are  standards  for  specifying,  it  would  expedite  the  implemen¬ 
tation  process  if  standards  were  defined  to  go  from  a  specification  to  an 
implementation.  The  user  guide  should  include  standards  for  (1)  going 
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from  the  specification  (e.g.,  a  control  map)  to  a  computer  allocation;  (2) 
real locationg  functions  to  a  computer,  and  (3)  providing  for  reconfigur¬ 
ation  of  functions  in  real  time. 


•  Definition  of  Development  Model  -  the  definition  of  a  de¬ 
velopment  model  is  most  helpful  to  the  manager  who  is  responsible  for  inte¬ 
grating  all  the  phases  of  development.  In  addition  to  the  above  recommen¬ 
dations,  the  development  model  should  define  phases  of  development  and  how 
to  integrate  them,  disciplines  {such  as  management,  design,  verification, 
implementation,  and  documentation)  and  an  integrated  application  of  tools 
and  techniques  that  are  to  be  used,  how  they  are  used  and  when  they  are 
to  be  used  throughout  the  development  process. 

1 . 9  Implications  and  Payoffs  for  the  Future 

In  order  to  change  to  new  techniques,  there  is  always  the  initial 
investment  that  is  necessary  for  defining  and  developing  a  model  (or 
subsets  thereof)  for  systems  in  general.  We  believe  that  a  great  deal 
of  work  necessary  for  this  step  has  already  been  accomplished  within 
our  own  methodology. 

A  next  step  is  to  define  a  set  of  additional  structures  and  data  types 
that  are  necessary  for  defining  a  particular  family  of  systems  (e.g., 

PLRS  is  a  member  of  a  particular  family  of  communications  systems). 

Once  the  initial  investment  has  been  made  to  establish,  what  in  essence, 
is  a  way  of  organizing  the  development  of  a  system  with  standards  and 
mechanisms  to  accomplish  that  organization,  the  payoffs  should  be  quite 
apparent.  Design  time  during  the  requirements/specifications  phase  should 
be  no  greater  and,  in  fact,  we  suspect  much  less  than  with  current  tech¬ 
niques.  Implementation  designs  should  take  considerably  less  time  than 
with  current  practices  since  it  is  possible  to  perform  such  a  process  on 
an  almost  one-for-one  basis.  We  suspect  that  the  largest  savings  will  be 
realized  within  the  verification  processes  since  most  of  the  recommended 
techniques  provide  standards  which  should  eliminate  errors  before  the 
fact  and  it  is  just  these  very  types  of  errors  that  we  spend  so  much  time 
looking  for  today. 
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2.0  THE  PLRS  PROBLEM 


The  Real  Time  PLRS  system  [It]  [14]  is  a  combined  communications  and  ranging 
(position  location  reporting)  system,  in  which  many  radio  User  Units  (UUs) 
are  deployed  in  a  field  of  operations,  carried  by  hand,  or  mounted  in 
planes,  helicopters,  tanks,  etc.  The  User  Units  communicate  with  one 
another  and  with  a  stationary  Master  Unit  (MU).  Transmissions  are  re¬ 
layed  to  and  from  the  Master  Unit  along  a  series  of  communications  links 
called  PORT  Links  (Figure  2-1).  The  User  Units  passively  receive  trans¬ 
mission  from  certain  other  User  Units  for  the  purposes  of  determining 
location,  and  the  Master  Unit  computes  the  position  of  each  User  Unit 
from  these  measurements  and  displays  it  to  the  human  operator.  Such 
passive  links  are  called  CROSS  Links.  The  network,  consisting  of  these 
PORT  Links  (forming  PORT  Paths  to  the  Master  Unit)  and  Cross  Links,  is 
continually  being  reconfigured  as  User  Units  enter  the  network  or  drop 
out,  as  certain  links  become  unreliable,  as  geographical  configurations 
of  units  change,  etc.  As  one  part  of  the  Real  Time  PLRS  system,  there  is 
a  module  called  the  Network  Manager  (NM)  whose  function  is  to  supervise 
the  continual  reconfiguration  of  this  communications  network.  This  re¬ 
port  discusses  some  aspects  of  the  specification  of  this  module  as  an 
illustrative  example  of  Higher  Order  Software  (HOS)  methodology. 

2.1  The  Need  for  Formal  Specifications 

In  the  sections  that  follow,  we  attempt  to  give  a  specification  using 
HOS  for  part  of  the  Network  Manager  module  of  the  Real  Time  PLRS  system, 
consisting  of  control  maps,  algebraic  data-type  specifications,  and  sample 
AXES  language  statements.  We  would  like  the  designer  to  communicate  his 
design  in  a  precise,  uniform  way,  as  well  as  make  changes  without  having 
committed  either  hardware  or  even  detailed  software;  for  the  user  to  re¬ 
view  and  verify  the  specification  in  detail  and  propose  revisions;  for 
the  programmer  to  receive  his  instructions  in  an  unambiguous  way,  so  that 
time  is  not  wasted  in  trying  to  resolve  conflicts  in  the  specification; 
and  for  the  manager  to  allow  the  flexibility  of  reusing  the  same  specifi¬ 
cation  in  different  situations  which  may  require  different  hardware  com¬ 
mitments  or  where  different  implementation  systems  may  be  available. 


frechhao  page  blank-not  nua 


This  exercise,  then,  is  to  take  a  section  of  an  actual  system,  the  Hughes 
Real  Time  PLRS,  and,  using  information  gained  from  some  of  Hughes  specifi¬ 
cations  as  well  as  discussing  the  problems  with  people  at  Hughes  and  Ft. 
Monmouth,  plus  making  some  hypothetical  assumptions,  to  demonstrate  how 
HOS  would  specify  the  system,  by  specifying  a  small  part  of  it. 

A  way  to  demonstrate  what  is  missing  from,  for  example,  the  Program 
Performance  Specif ications  (PPS)  [H] ,  is  by  presenting  a  trivial  example 
in  the  same  style.  We  might  try  to  specify  a  hypothetical  module,  the 
HOUSEKEEPER,  which  describes  some  of  the  functions  of  a  person  living  in 
a  house  (Fig.  2.1-1).  This  is  presented  in  the  style  of  the  PPS,  which 
also  accompanies  the  verbal  descriptions  by  diagrams  like  those  in  Fig¬ 
ure  2.1-2.  If  we  were  to  take  this  analogy  seriously  (for  example,  as  a 
class  exercise  in  flowcharting  for  a  beginning  computer  programming 
class),  we  already  note  some  glaring  inconsistencies.  That  is,  there  are 

(1)  ill-defined  functions  and/or  operations, 

(2)  syntactic  ambiguities, 

(3)  unspecified  assumptions, 

(4)  lack  of  hierarchical  structure  (how  it  fits  together), 

(5)  inconsistencies,  especially  in  I/O  interfaces, 

(6)  areas  where  control  could  be  lost  by  the  software  operator, 

(7)  redundancies. 

Although  we  may  assume  some  of  I/O  interface  inconsistencies  are  typo¬ 
graphical  errors,  these  problems  are  basically  problems  with  this  style 
of  exposition,  which  may  reflect  possible  problems  in  the  software  it 
represents.  In  Figure  2.1-1,  there  are  examples  of  (l)-(7)  as  follows: 

(1)  Sect.  3. 4. 2. 1.2. 2.  MAKING  SUBFUNCTION.  "Making"  dinner  and 
"making"  beds  are  not  only  not  the  same  operation,  but  have 
nothing  to  do  with  one  another. 

[2)  Sect.  3.4.2. 1.2.  STRUCTURE  OF  THE  HOUSEKEEPER.  Washes  what? 
Dishes?  Floors?  Furniture?  Dries  dishes?  Dries  furniture?!! 


21 


3. 4.2.1.  Housekeeper  Function;  The  function  of  the  housekeeper 

IS  TO  KEEP  THE  HOUSE. 

3.4.2. 1.1.  Inputs  to  the  Housekeeper  Function;  The  inputs  to  the 
Housekeeper  Function  are  those  listed  in  Appendix  J.  [We  turn  to 
Appendix  J  and  find  listed  "Brillo  Pads,  mop,  dishcloth,  laundry 
soap,  Ajax,  water,  dustmop,  dish  soap,..."  in  that  order.] 

3. 4. 2. 1.2.  Structure  of  the  Housekeeper;  The  Housekeeper  washes, 

DRIES,  DUSTS,  SHOPS,  AND  CLEANS  DISHES,  FLOORS,  AND  FURNITURE  AND 
MAKES  BEDS  AND  MEALS. 

3. 4. 2. 1.2.1.  Cleaning  Subfunction:  The  Housekeeper  cleans  several 

OBJECTS  AND  ROOMS. 

3. 4. 2. 1.2. 1.1.  Washing  Dishes:  The  Housekeeper  uses  dish  soap  and 

WATER  TO  WASH  DISHES. 

3. 4. 2. 1.2. 1.2.  Drying  Dishes:  The  Housekeeper  uses  a  dishtowel  to 
DRY  THE  DISHES.  [NOTE  DISHTOWEL  NOT  LISTED  IN  APPENDIX  J!] 

3. 4. 2. 1.2. 1.3.  Scrub  Bathtub:  Housekeeper  uses  Ajax  and  toilet 

BRUSH  (?!)  TO  SCRUB  BATHTUB. 

. . .  Etc. 

3. 4.2. 1.2.2.  Making  Subfunction:  The  making  subfunction  makes 

DINNER  WHICH  IS  OUTPUT  TO  FAMILY,  AS  WELL  AS  MAKING  BEDS  WHICH  ARE 
LOCATED  IN  SEVERAL  ROOMS.  THE  MAKING  SUBFUNCTION  DEPENDS  ON  THE 

Shopping  module. 

. . .  Etc. 

3.4.2. 1.2. 8:  Shopping  Subfunction:  The  Housekeeper  buys  various- 

supplies  TO  MAINTAIN  INVENTORIES  AT  A  SAFE  LEVEL  (A  SYSTEM  PARAMETER 
NO  MORE  MONEY  IS  SPENT  THAN  BUDGET  (A  SYSTEM  PARAMETER). 


GROCERY 

STORE 

DRUG 

STORE 

FAMILY 


Functions  of  HOUSEKEEPER 


Laundrv  soap 


Dish  soan 


clean  clothes 


* 


CLOSET 


Dish-cloth  [ 

WASH 

Clean  dishes 

Dirty  dishes 

DISHES 

_ . 

" .  '  > 

CLOSET 


There  are,  in  addition,  operation  tables: 


GATHER  WASH  DRY  STORE 


Wash-dishes 

x  ! 

X 

Wash-clothes 

•  x 

X 

X 

!  x 

1  i 

Figure  2.1-2 


(3)  Sect.  3. 4. 2. 1.2.1.  CLEANING  SUBFUNCTION.  Which  objects? 

Which  rooms? 

(4)  What  is  the  relation,  timing  and  otherwise,  between  kitchen 
(cooking)  functions,  cleaning  functions,  etc.?  For  example, 
washing  and  drying  dishes  presumably  follows,  not  preceeds, 
making  dinner. 

(5)  Sect.  3.4.2. 1 .2. 1 .1 .  No  dishcloth  is  listed  in  Figure  2.1-1 
as  input  to  WASHING  DISHES,  but  is_  listed  in  Figure  2.1-2  as 
input. 

(6)  Suppose  the  housekeeper  goes  out  shopping  to  obtain  food  (i.e., 
"inputs") and  meets  a  friend  instead,  goes  to  movies,  etc. 

and  doesn't  come  back  to  make  dinner. 

(7)  Sect.  3. 4. 2. 1.2.1.  CLEANING  SUBFUNCTION  is  not  only  not  a 
unitary  function,  but  adds  no  information  not  already  con¬ 
tained  elsewhere. 

Similarly,  we  find  examples  of  problems  (l)-(7)  in  the  PPS: 

(1)  What  is  PORT  Link  Assignment?  Since  this  is  the  central 
concept  in  the  Network  Manager,  it  seems  odd  that  it  does  not 
appear  in  the  PPS  glossary.  The  closest  thing  is  ASSIGNED 
PORT  LINK:  "a  communication  link  defined  by  a  set  of  active 
frames  specified  by  a  PORT  Link  Assignment,"  which  is  cir¬ 
cular.  Also,  as  will  be  discussed  later  in  this  report,  the 
PORT  Link  Assignment  function  itself  is  ill-defined,  in  that  it 
is  two-valued,  without  specifying  which  of  the  two  PORT  Link 
Assignments  is  being  referred  to  at  any  given  point.  (This 

is  discussed  in  Section  3.4.) 

(2)  The  draft  PPS  contained  the  sentence  shown  in  Figure  2.1-3a, 
which  we  interpreted  as  containing  the  two  underlined  noun 
phrases,  and  spent  a  good  deal  of  our  time  in  trying  to  deter¬ 
mine  what  a  "processing  link"  was.  The  correct  interpretation 
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of  the  sentence  is  shown  in  Figure  2 . 1 -3b.  This  is  an  un¬ 
avoidable  property  of  natural  language,  which  is  eliminated 
by  using  formal,  mathematical  specifications. 


3. 4. 2. 2  Network  Management  Processing:  The  Network  Management 
automatically  determines  and  maintains  PORT  and  Cross  Link  Assign¬ 
ments  for  each  UU  as  well  as  processing  1  ink  and  state  change 
requests. . . 

(a) 

3. 4. 2. 2  Network  Management  Processing:  The  Network  Management 
automatically  determines  and  maintains  PORT  and  Cross  Link  Assign¬ 
ments  for  each  UU  as  well  as  processing  link  and  state  change 
requests. . . 

(b) 

Figure  2.1-3 


(3)  The  section  from  PPS  shown  in  Figure  2.1-4  contains  a  sur¬ 
prising  bit  of  information,  which  we  were  unable  to  locate 
elsewhere.  Evidently,  for  each  User  Unit,  the  number  of  other 
User  Units  which  have  tried  to  gain  entry  to  the  system  through 
that  User  Unit  and  failed  is  a  parameter  being  stored  and  con¬ 
tinually  updated.  • 


3. 4. 2. 2. 1.5  Monitor  Entry  Requests:  A  UU  that  has  been  a  two- 
way  communicant  with  more  than  the  unsatisfied  entry  count  (sys¬ 
tem  parameters)  entry  requests  of  UUs,  for  which  a  PLA  was  not 
found,  shall  be  designated  for  PORT  Link  state  change. 


Figure  2.1-4 


(4)  In  Figure  2.1-5,  we  see  two  different  accounts  of  where  ZERO 
ALERTS  are  generated.  In  the  I/O  diagrams,  it  is  being  gene¬ 
rated  by  PORT  Link  Assignment  Control  (PPS,  p.  3-35/6),  but 


in  the  text,  it  is  described  as  generated  by  Network  Control 
(PPS,  p.  3-38). 


3. 4-2. 2.1  Network  Control _ _ 

3.4"2.2.1.1  UU  Entry  Requests...  When  a  PLA  is  not  found  for 
an  entering  UU,  a  zero  alert  shall  be  generated  for  that  UU. 


(5)  In  the  PPS  diagram  3. 3. 5-1  (p.  3-13/14),  ALERTS  is  an  input 
to  the  Network  Manager;  Figure  3.4. 2-1  indicates  it  to  be  an 
output.  The  former  indicates  no  output  from  the  Network 
Manager  to  the  POSITION  Tracking  Module;  the  latter  indicates 
"Unlocate  track  is  output  by  the  Network  Manager  to  Position 
Tracking."  There  are  many  discrepencies,  discussed  at  greater 
length  in  Section  5. 


(6)  The  example  cited  in  Figure  2.1-6  is  similar  to  the  "House¬ 
keeper"  shopping  example:  suppose  a  HANDOVER-IN  SUCCESSFUL 
notice,  for  whatever  reason,  never  arrives?  What  about  error 
recovery  here? 


3. 4. 2. 2.1 .1 .3  HANDOVER-IN  UUs.  Handover-in  UUs  shall  be 
initially  designated  as  being  in  the  zero  rate  PL  state  and 
shall  be  processed  by  PLA  control.  Network  control  shall 
generate  a  tree  allocation  command  containing  the  MU  tree 
allocation  to  all  handover-in  UUs.  Upon  acknowledgement  of 
this  command,  network  control  shall  generate  a  handover-in 
successful  notice. 


Figure  2.1-6 


(7)  As  we  will  see  later  in  the  discussion  of  control  maps,  state¬ 
ments  such  as  "Each  PLA  shall  be  supported  by  only  one  UU" 
are  either  meaningless,  false,  or  redundant.  See  Section 
of  this  report  for  a  complete,  discussion  of  this  issue. 

How  are  such  problems  discovered  by  attempting  to  do  an  HOS  specification, 
and  how  does  an  HOS  specification  eliminate  them?  This  report  tries  to 
illustrate  this  by  way  of  example.  Part  of  the  detection  of  these  problems 
was  done  in  the  early  stages  of  attempting  the  specification,  by  drawing 
a  preliminary  control  map  along  the  lines  of  the  Hughes  PPS.  This  was 
discussed  in  [16],  which  is  excerpted  in  Section  2.2  below.  Other  pro¬ 
blems  were  subsequently  detected  in  trying  to  formulate  the  data  types 
and  their  behavior;  some  of  this  was  also  discussed  in  [16]  .  A  com¬ 
plete  discussion  appears  in  Section  2.2  below.  In  Section  3 
we  will  discuss  a  control  map  for  one  subsection  of  the  Network  Manager. 

2.2  Preliminary  Control  Map 

Having  reviewed  the  STD  [14]  and  the  final  draft  of  the  PPS  [11]»  we  began 
to  define  a  control  map.  At  this  stage,  rather  than  doing  a  control  map 
"from  scratch,"  since  the  algorithms  in  many  cases  were 
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preliminary  control  map  was  done  directly  from  the  specification  in  the  PPS, 
without  regard  as  to  whether  it  followed  HOS  axioms.  This  gave  the  struc¬ 
ture  of  the  Network  Manager  as  it  is  presented  in  the  documentation.  By 
then  trying  (1)  to  correct  the  structure  of  the  control  map  and  (2) 
make  it  consistent  with  the  various  descriptions  of  the  Network  Manager 
at  various  levels  of  representation,  we  could  identify  potential  problem 
areas,  even  though  the  control  map  was,  at  this  stage  "content  free." 

That  is,  subroutines  were  simply  treated  as  lettered  subfunctions,  and 
the  partitions  given  in  the  text  accepted  without  regard  as  to  what  the 
subroutines  (subfunctions)  actually  did.  This  was  done  later.  Even  at 
this  stage,  however,  some  problems  are  identified.  For  example,  the 
PPS  contains  three  different  levels  of  representation  of  the  input/ 
output  structure  (see  Figure  2.2-1  for  exact  labeling). 


Level  a  -*■ 


Level  0  -*■ 


Level  y  -*• 


Figure  2.2-1 


If  we  take  fg  to  be  the  Network  Manager  function,  the  Figure  3. 3. 5-1  01] 
on  pages  3-13/14  corresponds  roughly  to  Level  a;  Figure  3. 4. 2-1  on  page 
3-35/56  01]  corresponds  to  Level  0;  and  the  verbal  descriptions  of  the  sub¬ 
functions  on  the  pages  following  page  3-37  [11]  correspond  roughly  to  Level  y. 
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The  first  thing  we  notice  is  that,  strictly  speaking,  this  control  map 
should  be  a  Class  Partition.  That  is,  if  Xj  =  (ag.a^ .ag.- .  .a^),  then 
x2  =  ^ak+l’ak+2^’*"an^’  etc'  as  we  to  cleePer  levels  of  representation. 

This  is  not  the  case  in  the  Hughes  PPS,  however. 

Sometimes  the  differences  are  "trivial"  in  that  the  same  name  is  not  used 
for  the  same  data  item  at  all  levels.  However,  while  this  may  seem 
trivial  (like  a  "typographical  error")  at  first  glance,  if  the  documenta¬ 
tion  is  to  be  relied  on,  it  is  at  best  confusing  for  manual  verification, 
and  it  is  death  for  machine  verification. 

For  example,  in  Figure  3. 3. 5-1  DT]>  the  I/O  inputs  UU  (User  Unit)  CONTROL 
to  the  NM  (Network  Manager);  in  Figure  3. 4. 2-1  [11],  it  inputs  UU  MODE  CONTROL. 
At  the  lowest  level,  that  of  the  verbal  description,  the  UU  Mode  Control 
Processing  subfunction  accepts  as  inputs  PASSIVE  MODE  REQUEST,  REENTER 
UU  REQUEST,  RESTART  UU  REQUEST,  CLEAR  UU  REQUEST,  REINITIALIZE  POSITION 
TRACK  REQUEST.  It  is  not  clear  which  of  these  are  part  of  the  data  item 
"UU  MODE  CONTROL"  from  the  I/O  and  which  are  not.  While  these  are 
discrepancies  in  the  documentation  (which  would  hopefully  be  more  pre¬ 
cisely  specified  enroute  to  coding),  the  HOS  control  map  allows  one  to 
see  immediately  which  inputs  at  different  levels  of  specification  must 
be  identical.  Thus,  one  can  prevent  inconsistencies  before  they  happen. 

Thus  we  see  two  kinds  of  problems  right  away.  As  we  go  from,  for  example, 
Level-j  to  Level ..+j,  either  we  must  have  the  same  set  of  input  variables 
(Figure  2.2-2) 


Level.  (yry2)  *  f(x0>...,  xn) 


Le.el,.+i  y-j  =  g(xQ,...,xk)  y2  =  h(xk+1 , . . .  ,xn) 


Figure  2.2-2 
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or,  if  one  wished  to  abbreviate  for  compactness  of  presentation,  one  would 
have  to  be  very  careful  to  specify  which  input  variables  at  Level ^  were 
represented  by  which  variable  at  Level .  (Figure  2.2-3): 


(yry2)  =  f(zi*z2) 


where  =  xQ,...yk  and  yK+1>- • *xn.  This  may  seem  unnecessary  for  such 
a  simple  partition  as  the  one  above,  or  even  a  small  part  of  the  NM, 
especially  at  the  top  levels  (0,1,2,  etc.).  However,  in  the  more  detailed 
specifications  (lower  levels  of  the  control  map  tree),  the  chances  for 
error  multiply  rapidly  without  keeping  this  in  mind.  The  control 
map  and  axioms  force  one  to  be  consistent  from  top  to  bottom.  This  is 
even  more  apparent  if  one  thinks  of  a  PLRS  Master  Unit  as  being  Level q, 
and  the  NM  as  being  one  section  of  a  lower  level. 

Another  area  in  which  the  control  map  can  be  helpful  is  in  identifying 
where  the  same  data  items  (or  subparts  of  the  same  data  items)  are  being 
input  to  two  different  modules.  For  example,  in  the  accompanying  pre¬ 
liminary  control  map  done  from  the  PPS  (see  Figure  2.2-4),  x'^  =  x'21  = 
COMMUNICANTS,  x'g  =  x'15  =  x'22  =  x'24  =  COMMAND-ACKNOWLEDGE .  This  is 
partly  simply  a  matter  of  clarity  and  perspicuity.  However,  one  then  wants 
to  ask  whether  they  are  to  be  treated  as  unitary  items,  or  whether  they 
are  being  input  to  several  functions  implies  a  partition,  as  in  the  Class 
Partition  exemplified  above.  In  terms  of  the  control  map,  for  example, 
the  input  from  the  Master  Traffic  Control  (MTC)  at  level  a,  x^  =  COMMAND 
RELIABILITY  (from  01]  Figure  3. 3. 5-1)  is  presumably  partitioned  into 
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PRELIMINARY  CONTROL  MAP  FOR  THE  NETWORK  MANAGER 


PRELIMINARY  CONTROL  MAP  for  the  Network  Manager 
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Figure  2.2-4  (con't) 
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Figure  2.2-4  (con't) 
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into  x'^g,  x'2g»  and  which  are  PLA  (PORT  Link  Assignment)  COMMAND 

RELIABILITY,  CLA  (CROSS  Link  Assignment)  COMMAND  RELIABILITY,  and  SECONDARY 
MU  (Master  Unit)  COMMAND  RELIABILITY  at  Level  3. 

Another  question  one  wants  to  ask,  based  on  the  control  map,  is  what  func¬ 
tional  relationship  the  module  (subfunction)  Adjacent  MU  Communications 
Assignment  bears  to  the  rest  of  the  Network  Manager,  i.e.,  the  Network 
Control  subfunction,  CLA  Control ,  and  PLA  Control .  Other  than  the 
common  input/output  COMMAND  ACKNOWLEDGE  and  COMMAND  REQUESTS,  (which  we 
take  to  be  general  terms,  not,  in  fact,  referring  to  the  same  data  items), 
there  seems  to  be  no  connection.  In  terms  of  HOS  primitives,  it  is 
neither  a  Set  Partition,  a  Class  Partition,  and  certainly,  not  a  Composi¬ 
tion.  Nor  does  it  seem  to  be  an  abstract  Control  Structure  derived  from 
these  primitives.  Thus,  one  might  question  the  validity  of  having  it 
as  part  of  the  Network  Manager  function. 


A  more  important  problem  is  that  the  control  map  shows  that  in  some  cases 
the  functions  are  not  cleanly  divided,  i.e.,  that  there  is  a  lack  of 
modularity.  In  plain  language,  there  is  confusion  about  which  subfunction 
does  what.  For  example  if  we  look  at  Level  3  (the  one  which  represents  PPS 
Figure  3. 4. 2-1)  on  the  control  map,  we  see  that  the  PLA  Control  generates 
the  output  yg  =  ZERO  LINK  ALERT  (and  similarly  for  other  ALERTS).  But 
if  we  look  at  Level  y  which  represents  the  verbal  subdivision  later  in  the 
Hughes  document,  we  find  ZERO  LINK  ALERT  being  generated  by  the  UU  Entry 
Request  subfunction  (this  corresponds  to  the  statement  in  PPS  on  page  3-38 
under  the  description  of  the  Network  Control  subfunction,  "3. 4. 2. 2. 1.1 

UU  Entry  requests _ When  a  PLA  is  not  found  for  an  entering  UU,  a  zero 

alert  shall  be  generated  for  that  UU").  The  representation  as  a  control 
map  makes  it  immediately  transparent  that  one  of  the  descriptions  must 
be  incorrect,  since  two  subfunctions  in  two  distinct  parts  of  the  control 
map  cannot  generate  the  same  identical  data  item. 

While  this  may  seem  obvious  on  an  intuitive  level  (i.e.,  that  two  distinct 
subfunctions  cannot  output  the  same  item--it  is  either  output  by  one  or 
by  the  other),  it  is  important  to  point  out  that  (1)  the  control  map, 
because  it  has  several  levels  in  the  same  representation,  makes  it  easy 
to  check  for  such  inconsistencies,  and  (2)  on  a  theoretical  level,  we 
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note  that  it  violates  one  of  the  formal  HOS  axioms  for  the  construction 
of  control  maps  and  AXES  specifications,  namely 

AXIOM  1:  A  given  module  controls  the  invocation  of  the  set  of 
functions  on  its  inmediate,  and  only  its  immediate 
lower  level. 

By  extension,  there  is  no  way  the  PLA  Control  could  invoke  the  UU  Entry 
Request  subfunction,  since  UU  Entry  Request  is  the  inmediate  lower  level 
of  Network  Control ,  not  PLA  Control . 

Again,  it  should  be  pointed  out  that  although  in  this  simple  case  it  seems 
obvious  that  the  verbal  description  is  in  error,  rather  than  the  flow  dia¬ 
gram,  the  control  map  provides  a  way  for  catching  this  immediately  and 
a  formal  resolution  for  more  complicated  cases. 

A  further  problem  which  is  uncovered  by  the  control  map  is  that  as  one 
descends  into  more  detailed  levels  of  representation,  inputs  (or  outputs) 
are  introduced  that  didn't  appear  at  all  in  the  higher  levels  of  repre¬ 
sentation.  This  is  different  from  unclarity  (vagueness  or  discrepancies) 
in  representing  a  particular  input  item  or  items  at  different  levels. 

% 

For  example,  some  variables  which  appear  at  Level  y  (like  x"8  =  REENTER 
UU  REQUEST)  also  appear  at  Level  B  (in  this  case  as  x'^  —  in  a  proper 
control  map  both  should  be  designated  by  the  same  variable).  However, 
seemingly  analogous  variables  at  Level  y,  such  as  x"g  =  RESTART  UU 
REQUEST,  do  not  appear  at  Level  B  at  all.  This  corresponds,  again  to 
the  Hughes  PPS  Section  3.4. 3. 3.1 .2.3  on  pages  3-38,  where  we  find  "Upon 
receipt  of  a  restart  UU  request..."  analogously  to  Section  3. 4. 2. 2.1 .2.2, 
"Upon  receipt  of  a  reenter  UU  request..."  However,  in  Figure  3. 4. 2.1 
(the  B  Level),  there  is  only  the  REENTER  UU  REQUEST  being  input  from 
the  MTC.  Similarly,  the  HANDOVER-IN  REQUEST  appears  on  the  y  Level 
and  the  3  Level,  but  the  CLEAR  UNIT  REQUEST  only  appears  on  the  y  Level. 

It  should  be  pointed  out  that  this  sort  of  discrepancy,  while,  of  course, 
violating  HOS  Axioms,  is  particularly  unfortunate  from  the  point  of  view 
of  the  Hughes  PPS.  Since  it  is  in  the  B  Level  representation  (Figure 
3. 4. 2-1)  that  we  are  shown  which  modules  external  to  the  NM  input  various 
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data  to  subfunctions  of  the  NM,  if  a  new  data  input  appears  at  the  lower 
y  Level  (the  more  detailed  verbal  descriptions  in  Section  3. 4. 2. 2  ff), 
then  we  have  no  way  of  telling  where  (i.e.,  which  subfunction)  the  data 
item  comes  from.  In  fact,  for  all  one  knows,  the  inputs  could  be  output 
coming  from  either  external  or  internal  modules,  since  this  is  simply 
not  stated,  and  one  has  to  either  guess  as  to  the  source  of  the  data 
or  search  elsewhere  in  the  documentation. 

The  advantages  of  a  control  map  in  this  respect  are  that  input  variables 
of  a  subfunction  which  are  external  (i.e.,  come  from  a  source  outside 
the  subfunction)  MUST  be  carried  through  at  all  levels,  so  that  in  the 
complete  control  map,  one  can  always  trace  the  source.  For  example,  if 
a^  is  an  input  to  the  Network  Control  subfunction  of  the  Network  Manager, 
and  that  input  comes  from  the  MTC  module,  then  in  the  complete  PLRS 
control  map  one  could  trace  the  input  as  shown  (Figure  2.2-5): 


(...)  =  NM(...a. ..) 


(...a...)  =  MTC( — ) 


Fiaure  2.2-5 


Finally,  since  input  and  output  varibles  must  be  carried  through  the 
control  map  as  shown  above,  the  preliminary  Network  Manager  control  map 
uncovers  another  problematic  aspect  of  the  Network  Manager,  as  described 
in  the  PPS,  namely  calls  to  subroutines  outside  the  module  in  question. 
These  show  up  as  the  following  structure  (Figure  2.2-6): 

(...)  NM( . . . )  (...)=  MTC( . . . ) 


(y)  =  fk(x) 


If  we  take  w  (  =  x"4)  =  TREE  ALLOCATION  COMMAND,  and  z  (  =  y"2)  =  COMMAND 
ACKNOWLEDGEMENT,  then  according  to  Section  3. 4. 2. 2. 1.1. 3  “Handover-in  UUs" 
on  page  3-38,  which  is  a  subfunction  of  Network  Control:  "...Network 
Control  shall  generate  a  tree  allocation  command  containing  the  MU  tree 
allocation  to  all  handover-in  UUs.  Upon  acknowledgement  of  this  command. 
Network  Control  shall  generate  a  handover-in  successful  notice."  That  is, 


1 


some  subfunction,  f^,  of  the  Network  Control  function  computes  (generates) 
y  =  HANDOVER-IN  SUCCESSFUL  NOTICE.  However,  we  notice  that  part  of 
fk>  namely  the  subfunction  f 2  computes  a  value  z,  which  is  the  input  to 
an  entirely  different  module  (e.g.,  MTC),  which  in  turn  generates  a  value, 
w,  which  is  the  input  to  another  subfunction,  f^,  of  the  function  f^. 

Not  only  do  "hidden"  calls  to  external  functions  destroy  modularity,  but 
in  this  case,  there  is  no  provision  for  error  recovery  should  an  acknowledge¬ 
ment  fail  to  be  generated.  This  is  clearly  shown  by  the  preliminary 
control  map,  i.e.,  this  would  be  invalid  in  a  proper  control  map,  since 
a  function  can  control  the  access  rights  only  to  the  inputs  and  outputs 
of  its  immediately  dominated  subfunctions,  and  here  we  have  some  function 
external  to  the  Network  Manager  accessing  an  internal  output  of  a  sub¬ 
function  of  the  Network  Manager  and  vice  versa. 

2.3  Understanding  Data  Properties 

Once  a  preliminary  survey  of  the  system  was  made  from  the  available 
documents,  one  of  our  first  tasks  was  to  identify  the  important  data 
types.  This  turned  out  to  be  a  particularly  difficult  task  in  this 
system,  since  there  are  many  parameters  (usually  integers)  used  by  the 
Network  Manager  which  have  only  peripheral  importance.  What  turned 
out  to  be  the  central  and  crucial  data  types  for  the  Network  Manager 
operation  were  quite  complex  and  idiosyncratic  objects.  Most  of  our 
time  was  therefore  spent  on  understanding  the  properties  of  these  data 
types  before  we  could  specify  operations  employing  them.  Why  this  was 
so  is  discussed  in  detail  in  the  next  section. 
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3.0  THE  PLRS  DATA  TYPES 


3.1  The  Network  Manager 


Turning  now  to  our  specification  of  the  Network  Manager  (NM),  what  do  we 
need  to  know  in  order  to  do  the  specification?  Already  at  this  first 
stage,  the  control  map  format  provides  a  guideline  as  to  the  appropriate 
questions  to  ask  first.  We  know  that  the  top  level  of  the  control  map 
will  have  the  format: 

y  =  f(x) 


That  is,  we  must  immediately  begin  thinking  of  the  problem  in  terms  of 
mathematical  functions  (mappings)  acting  on  some  input(s)  to  produce 
some  output(s):  £  performs  some  action  or  computation  on  to  produce 
What  are  the  x,y,  and  f  of  the  Network  Manager?  A  not  unreasonable 
first  assmption  is  that  y  =  f(x)  takes  the  form 

Network^  =  MANAGE  (Network^) 

That  is,  the  Network  Manager  (NM)  takes  as  input  some  state  of  the  Network 
(Network^)  and  performs  some  operations  on  it  (the  function  MANAGE)  to 
produce  a  new,  reconfigured  state  of  the  network  (Network^) .  As  it 
turns  out,  there  are  other  inputs  to  the  Network  Manager  other  than 
just  the  current  state  of  the  Network:  the  NM  must  also  know  (1)  the 
History  of  the  network  (e.g.,  the  Unsatisfied  Entry  Count,  which  is  a 
record  for  each  User  Unit  (UU),  of  the  number  of  other  units  which  have 
tried  to  gain  entry  to  the  system  through  that  UU  and  failed);  and 
(2)  Requests,  for  example,  a  request  from  the  human  Operator  to  force 
a  particular  assignment.  There  will,  of  course,  also  be  certain  second¬ 
ary  outputs  regarding  the  state  of  the  network  and  the  result  of  the  ac¬ 
tions,  such  as  ERROR  messages,  REQUESTS  for  more  information  to  be  sent 
to  the  Message  Traffic  Control  (MTC),  and  the  like.  Thus  the  top-level 
function  should  really  be  something  like: 


(NetworkNrU,  Messages)  =  MANAGE ( Networkn,  n  ,  History,  Requests) 


fRECXSlNQ  PiOS  BLANK-NOT 
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These  secondary  inputs  and  outputs  indicated  in  Equation  (2)  should  not 
distract  us  from  remembering  that  the  basic  function  of  the  NM  is  to 
reconfigure  the  network,  as  indicated  in  Equation  (1).  Now  in  order  to 
begin  to  describe  this  basic  function,  we  have  to  set  our  priorities. 

Do  we  want  to  begin  by  looking  at  the  actions  (the  function  MANAGE)  or 
on  the  object  acted  upon  (the  Network)?  By  casting  the  problem  in  this 
format,  the  HOS  control  map  has  already  forced  us  to  make  a  decision 
of  this  sort  by  highlighting  the  issue  involved.  In  the  case  of  PLRS, 
the  answer  is  fairly  straightforward:  a  preliminary  survey  of  the  pro¬ 
blem  indicated  that  the  structure  of  the  network  was  so  extraordinarily 
complex,  that  we  really  needed  to  understand  it  thoroughly  first,  before 
we  could  expect  to  talk  about  the  MANAGE  function  in  any  reasonable  way. 

3.2  Why  Data  Types? 

What  does  it  mean  to  understand  the  structure  of  the  Network?  We  know, 
of  course,  that  we  will  have  to  have  some  intuitive  understanding  of 
the  Network  as  a  working  hypothesis.  But  can  we  at  some  point  say  that 
we  have  understood  the  Network  and  are  ready  tomove  on  to  the  next  step? 

Here  again,  the  HOS  methodology  provides  an  answer:  we  can  begin  describing 
the  operations  when  we  have  identified  the  data  types  and  have  specified 
their  behavior  by  a  set  of  primitive  operations  and  axioms.  This  defines 
the  behavior  of  the  data  types  so  that  we  can  go  ahead  with  the  control 
map  (and  specify  other  operations  on  those  data  types),  because  we  know 
from  the  axioms  what  is  permissible  and  what  is  not. 

What  iv.kes  the  PLRS  network  so  particularly  complicated?  (Why  are  its 
data  types  so  difficult  to  specify?)  There  are  several  reasons: 

1.  The  PLRS  data  types  are  unique  to  the  PLRS  system.  In  other 
systems,  we  may  be  working  with  such  data  types  as  files,  vectors,  scalars, 
lists,  rational  numbers,  about  which  (a)  people  already  have  an  intuitive 
understanding,  and  (b)  there  already  exists  a  reference  literature,  both 
mathematical  and  computational,  describing  their  properties.  The  objects 
which  form  the  basis  of  the  PLRS  Network  User  Units  (UUs)  and  Logical 
Times  (LTs)  are  idiosyncratic  objects,  some  of  whose  properties  are  de¬ 
termined  by  the  particular  implementation  suggested  in  the  Hughes  documents. 
In  a  completely  general  specification,  this  might  not  be  true. 
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2.  The  PLRS  system  is  duplexed.  This  means  that  the  mapping 
which  relates  UUs  and  LTs  will  not  be  a  simple  one-to-one  correspondence. 

3.  The  organization  of  Logical  Time  is  itself  complex.  Because 
groups  of  time  slots  are  interleaved  with  one  another  (even  before 
scrambling).  Logical  Time  is  not  a  simple  cyclic  domain,  but  rather 
has  a  complex  internal  structure,  which  we  must  abstract  away  from  in 
order  to  state  what  the  simple  operations  relevant  to  the  Network  Manager 
are.  (More  on  this  below.) 

One  might  want  to  ask  (particularly  in  view  of  the  complexity  of  the  data¬ 
type  specifications  for  PLRS),  why  should  one  care?  Isn't  there  some 
easier  way  to  specify  the  system? 

In  this  case,  the  data-type  specifications  are  particularly  important 
for  the  reason  given  in  Item  (1)  above:  the  data-types  are  unique  to  the 
system.  We  already  know  what  to  expect  from  vectors  or  rational  numbers 
(for  example,  that  one  cannot  divide  by  zero);  about  these  idiosyncratic 
data  types  we  have  no  idea  what  to  expect  in  either  of  two  cases: 

(1)  What  operations  are  possible  (e.g.,  have  we  overlooked  a 
possible  operation  which  would  allow  the  program  to  run  more 
efficiently) ; 

(2)  What  operations  are  invalid  (e.g.,  they  yield  no  output  or  an 
incorrect  output,  causing  a  system  error). 

Trying  to  define  the  data  types  carefully  in  advance  can  help,  for  ex- 
amrla.  the  programmer  who  subsequently  uses  them  to  know  what  can  and 
cannot  be  done. 
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3.3  PORT  Link  Assignment 

The  basic  concept  of  the  Network  is  PORT  Link  Assignment,  which  is  defined 
as  follows:  On  the  one  hand  there  are  User  Units  ( rad io-correnuni cation 

units),  and  on  the  other  hand  there  are,  for  each  User  Unit,  a  set  of 

time  intervals  in  which  that  User  Unit  is  allowed  to  operate.  The  mapping 
which  assigns  UUs  to  the  set  of  time  intervals  in  which  they  are  to  operate 
(transmit)  is  called  PORT  LINK  ASSIGNMENT.  The  Hughes  documents  tend  to 
be  ambiguous  in  this  respect,  using  the  term  "Port  Link  Assignment"  (PLA) 

to  mean  both  the  process  of  mapping  UUs  onto  time  intervals,  as  well  as 

the  set  of  time  intervals  a  UU  is  mapped  onto.  Hence,  we  find  such 
apparently  anomalous  phrases  as  "unassigned  PORT  Link  Assignment,"  which 
actually  means  a  set  of  time  intervals  which  has  not  yet  been  assigned 
to  a  UU  by  the  PORT  Link  Assignment  function*.  In  order  to  avoid  con¬ 
fusion,  in  this  report  PORT  Link  Assignment  will  be  used  to  refer  only 
to  the  mapping,  or  assignment  process,  and  the  term  Logical  Time  (LT) 
to  represent  the  set  of  time  intervals  which  is  assigned  to  a  particular  UU. 

Thus,  it  would  seem  our  basic  data  types  would  be  User  Units  and  Logical 
Times,  since  the  BASIC  activity  of  the  Network  Manager  is  to  assign 
a  UU  to  one  or  more  LT's:  PORT  Link  Assignment.  Of  course,  the  Network 
Manager  has  other  functions  as  well:  the  secondary  assignments,  known 
as  CROSS  LINK  ASSIGNMENTS  (for  listening  rather  than  transmitting)  plus 
certain  "housekeeping"  or  "clean-up"  functions,  which  are  needed  to  readjust 
the  Network  when  a  UU  is  reassigned.  But  we  must  not  let  this  obscure 
the  basic  assignment  function. 

Now  i~  -.urns  out  that  the  UUs  are  related  to  one  another  in  certain  ways, 
and  the  LTs  are  also  related  to  each  other  in  certain  complex  ways. 

A  way  of  thinking  about  this  which  has  proved  helpful  in  defining  the 
data  types  is  to  imagine  a  space,  or  universe,  of  UUs  and  another  space, 
or  universe,  consisting  of  Logical  Time  intervals;  PORT  Link  Assignment 
maps  element  in  one  space  onto  elements  in  the  other  (Figure  3.3-1). 
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3.4  User  Units 


Let  us  first  consider  the  User  Units.  Before  we  can  state  a  formal  algebraic 
definition  of  the  data  types  User  Units  and  Logical  Time,  we  need  to  have  some 
intuitive  understanding  of  how  they  function,  how  they  are  related,  and 
what  operations  on  them  are  basic.  In  the  case  of  the  UUs,  we  know  that 
each  data  UU  represents  an  actual  radio-communication  device  in  the  field. 
Messages  from  the  Master  Unit  (MU)  may  be  transmitted  to  some  UUs  directly, 
to  others  by  being  relayed  along  a  chain  of  UUs.  Similarly,  inbound  mes¬ 
sages  from  some  UUs  are  transmitted  to  the  MU  directly,  others  relayed 
via  a  chain  of  links  between  other  UUs.  These  are  the  PORT  Links,  and 
together  they  form  a  PORT  Path  between  a  UU  and  and  the  MU.  We  can 
visualize  this  as  a  tree-like  structure  with  the  MU  at  the  bottom,  trans¬ 
mitting  up  the  links  to  the  UUs  as  shown  in  Figure  2-1.  (Return  messages 
are  relayed  back  along  the  same  paths.)  If  two  User  Units,  U.  and  U., 

1  J 

are  connected  by  a  relay  link,  as  shown  in  Figure  2-1,  we  will  say  that 
that  U.  U-supports  Uj,  meaning  that  U^  transmits  to  Uj  outbound  from  the 
MU,  and  receives  from  U-  inbound  toward  the  MU.  The  notion  of  U-SUPPORT, 

J 

then,  will  be  the  basic  relation  that  UUs  have  with  each  other. 

We  notice  that  in  this  system  (as  described  in  the  Hughes  documents), 

U-SUPPORT  as  a  relation  between  UUs  has  several  properties,  which  are 
reflected  in  the  axioms  for  data-type  UU  (Figure  3.4-1).  First,  we 
would  like  to  say  that  U-support  is  transitive  along  the  branches  of  a 
tree:  if  U]  U-supports  and  U^  U-supports  U^,  then  U^  also  U-supports 
(indirectly)  U^.  This  is  stated  in  Axiom  2.  Also,  we  would  like  to  say 
that  i  '  cannot  occur: 


PORT  Path  1 
PORT  Path  2 


Figure  3.4-2 
Forbidden  Configuration 
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DATA  TYPE:  UU;  /*liser-un  i  t*/; 

PRIMITIVE  OPERATIONS: 

boolean  =  Usupp?  (uu^,  uu^) ; 
tuple(of  logical  tine)  =  PLA(uu); 

UU  =  ALP  (logical  time); 

AXIOMS: 

WHERE  u,uru2  ARE  UU  1  s  ; 

WHERE  M  IS  A  CONSTANT  UU; 

WHERE  trt2  ARE  LOGICAL  TIMES; 

WHERE  n  IS  A  NATURAL; 

(1)  (Usupp? (u1 ,u2) 3Not  (Usupp?  (u2,u1)))  =  True; 

(2)  ( (Usupp? (u1 ,u2)  &  Usupp?(u2,u^)) 3Usupp?(u1 ,u^))  =  True 

(3)  (Not (Eq (u,M) ) D Usupp? (M,u) )  =  True; 

(4)  Not (Usupp?  (u,u) )  =  True; 

(5)  ALP (Exami ne  I  tern (PLA (u) ,n) )  =  ]u  OTHERWISE  .  (2U) ; 

—  Reject 

PARTITION  OF  (u,n)  IS 

^  (u,n)  |  (1  ^  n  <_  2  &  u^M) !  (l  <_  n  <_  6  &  u=M) , 

2 ( u, n ) | n=0 ! (n  >  2  &  u^M) ! (n  >  6  &  u=M) ; 

(6a)  (Tsupp?  (t 1 , t2) 3 Usupp? (ALP (t 1 ) ,ALP (t2) ) )  =True; 


Ficure  3.4-1 
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(6b)  (Usupp?(uru2)  =  (0R(Tsupp?(ID^(PLA(u])),ID^(PLA(u2))), 

(Tsupp? (ID^(PLA(uj)),ID2 (PLA(u2) ) ) , 
(Tsupp?(ID2(PLA(u])),ID^(PLA(u2))), 
(Tsupp? ( ID2 (PLACu, ) ) , ID| (PLA(u2) )) ,) 

OTHERWISE  (OR (Tsupp? (ID* (PLA(2U] ) ) , ID2 (PLA(2u2) ) ) , 
(Tsupp? ( I D2 (PLA (2u^ ) ) , ID2 (PLA (2u2) ) ) , 
(Tsupp?(ID^(PLA(2u])),ID2(PLA(2u2))), 
(Tsupp?  ( I D* (PLA(2U] ) ) , ID2 (PLA(2u2) ) ) , 
(Tsupp? ( I D* (PLA (2U] ) ) , ID2  (PLA(2u2) ) ) , 
(Tsupp?  ( I (PLA (2u  j ) ) , ID2 (PLA (Zu2 ) ) ) , 
(Tsupp? (ID^(PLA(2a1)), ID2 (PLA (2u2))), 
(Tsupp? ( I D* (PLA (2Ul ) ) , ID2 (PLA  (2u2) ) ) , 
(Tsupp? ( I D*  (PLA(2U] ) ) , ID2 (PLA(2u2) ) ) , 
(Tsupp? (ID^(PLA(2u] )), ID2 (PLA  (2u2))), 
(Tsupp? (ID^ (PLA (2U])), ID2 (PLA (2u2))), 
(Tsupp? ( ID| (PLA(2U] )) , ID2 (PLA(2u2))), 

OTHERWISE  Kn  .  ,3  3  \ 

Reject  (  Uj ,  u  ); 

PARTITION  OF  (u  ,u  )  IS 

,(u),u2) 

2 

(Uj ,Uj)  u j  =MSu2^M , 

3(uru2)  UjXMSu^M; 

END  UU: 

N.B.  OR  =  n  -  place  Logical  Or 

Figure  3.4-1  (con't) 
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That  is,  if  Uj  U-supports  l^,  then  cannot  U-suppori  U^.  It  should  be 
noted  that  this  property  is  not  guaranteed  a  priori,  but  rather  must  be 
ensured  by  the  way  the  search  algorithm  for  finding  PORT  Link  Assignments 
is  constructed.  We  will  therefore  see,  when  we  examine  the  control  map, 
that  this  corresponds  to  one  of  the  test  modules  in  the  program.  We  also 
note,  and  this  is  important,  that  although  the  Master  Unit  is  clearly 
different  in  many  respects  from  the  User  Units,  it  does  behave  like  them 
in  that  it  particupates  in  the  U-SUPPORT  relationship.  Specifically, 
it  U-supports  al 1  the  UUs  in  one  of  its  tree-like  networks  (Axiom  3). 

This  is  important  for  consistency  in  applying  tests  to  pairs  of  UUs: 
if  we  ask  (in  Figure  2-1),  "Does  unit  U.  support  unit  U.?",  we  want  the 

1  J 

answer  to  be  yes  (TRUE);  similarly,  if  we  ask  does  the  Master  Unit  M 
support  unit  U-,  we  also  want  the  answer  to  be  yes.  Thus  the  Master 
Unit  behaves  very  much  like  zero  among  the  natural  numbers:  zero  is 
a  number,  the  operation  of  addition  and  subtraction  can  validly  be  per¬ 
formed  with  it,  and  it  can  be  the  valid  result  of  an  operation;  but  it  is 
also  different,  e.g.,  one  cannot  divide  by  zero. 

In  particular,  it  turns  out,  due  to  the  way  the  PLRS  system  is  structured, 
that  one  Master  Unit  can  U-support  several  tree-like  networks  (at  dif¬ 
ferent  times,  or  at  different  frequencies;  of  course),  up  to  six;  a  UU 
can  U-support  units  in  no  more  than  two  trees  (Figure  3.4-3). 


Fiaure  3 .4-3 
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This  is  reflected  in  the  way  PORT  Link  Assignments  (PLAs)  are  made:  notice 
that  UUs  are  assigned  two  Logical  Times  by  the  operation  PLA,  except  for 
the  MU,  which  is  assigned  six  (e.g.,  PLA(ui)  =  (LT^  ,  LT2  )).  But  to  see 

why  this  is  related  to  U-SUPPORT,  we  need  first  to  consider  the  other 
data  type,  Logical  Time. 

3.5  Logical  Time 

In  the  PLRS  system,  time  is  cyclic;  transmissions  are  scheduled  to  occur 
over  particular  links  at  regular  intervals,  the  rate  depending  on  such 
things  as  the  kind  of  unit  involved;  airborne  units  transmitting  more 
frequently  than  manpack  units,  for  example.  Recall  the  tree-like  net¬ 
work  consisting  of  UUs,  a  MU,  and  the  links  between  them  (Figure  2-1). 

Now, each  one  of  the  links  between  two  UUs  is  a  radio-communication  link, 
and  thus  occurs  during  some  time  interval.  (For  the  sake  of  this  example, 
we  consider  only  outbound  transmissions.) 

Imagine  these  time  intervals  superimposed  upon  the  link  tree  network  as 
shown  in  Figure  3.5-1,  where  each  color  indicates  the  set  of  time  inter¬ 
vals  of  one  PORT  path.  Now  Logical  Time  is  organized  into  EPOCHS  (64 
seconds  long)  which  are  subdivided  into  256  FRAMES,  each  of  which  con¬ 
sists  of  128  smaller  time  intervals  (Figure  3.5-2a).  An  appropriate 
image  of  what  happens  is  to  imagine  the  time  intervals  in  Figure  3.5-1 
as  colored  neon  lights,  and  there  is  a  flash  up  and  back  one  of  these 
PORT  paths  in  each  of  the  256  frames  of  an  epoch.  Clearly,  many  of  them 
will  flash  more  than  once  and  at  regular  intervals.  Since  there  are, 
however,  128  time  intervals  in  each  frame,  and  (as  we  shall  see  later) 
since  PORT  paths  are  limited  to  no  more  than  four  levels,  the  Logical 
Time  intervals  corresponding  to  PORT  Paths  in  several  different  trees 
(networks)  could  flash  during  one  Frame. 

Now  imagine  a  string  tied  to  the  bottom  on  each  of  the  sets  of  time 
intervals  corresponding  to  one  of  the  PORT  paths  in  the  tree-network 
of  Figure  3.5-1,  and  both  ends  pulled  apart  so  that  all  of  the  columns 
of  time  intervals  stood  up  vertically  from  a  base  (as  in  Figure  3.5-3). 

We  could  then  also,  as  it  were,  tip  all  of  the  columns  of  time  intervals 
over  on  their  sides  so  they  would  lie  end-to  end--this  would  then  give 
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Representative  Time  Slots  for  the  Network  in  Figure 
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Figure  A.  The  Cyclic  Timing  Structure  of  a  PLRS  Network  is  Divided  into  Epochs,  Frames,  and 
Time  Slots.  Only  one  community  member  at  a  time  can  transmit  a  burst  during  any  given  time 
slot.  Most  actions  that  a  User  Unit  can  be  programmed  to  do  are  repeated  each  epoch. 


EPOCH  =  256  FRAMES 
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FRAME  128  TIME  SLOTS 
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Figure  B.  The  Time  Divisions  of  the  PLRS  EDM.  The  capacity  of  the  PLRS  network  is  based  on 
128  time  Mots  within  each  of  256  frames  (total  of  32.768  time  slots  per  epoch). 


Figure  3.5-2 


Figure  3.5-3 


us  a  linear  sequence  of  time  intervals  (Figure  3.5-4,  upper  left-hand 
corner)  which  is  necessary,  because  time  is,  in  fact,  linear. 

There  are  two  additional  factors  which  complicate  this  rather  straight¬ 
forward  interpretation  of  logical  time  (as  represented  in  Figures  3.5-1, 
3.5-2,  3.5r3).  Both  can  be  ignored,  for  all  practical  purposes,  by  the 
Network  Manager  but  need  to  be  mentioned  briefly,  so  as  to  avoid  con¬ 
fusion  later.  Each  of  the  columns  in  Figure  3.5-3  represent  only  outbound 
transmissions.  Since,  in  reality,  transmissions  are  both  inbound  and 
outbound,  there  must  be  more  than  four  time  intervals  involved.  In  fact, 
there  are  16,  structured  as  shown  in  Figure  3.5-5.  While  there  is  only 
one  outbound  transmission  by  each  UU  along  a  PORT  Path,  there  are  several 
inbound  transmissions,  and  in  addition,  one  time  interval  (the  fifth) 
is  reserved  for  special  purposes,  such  as  requesting  entry  into  the  network. 
One  set  of  16  time  intervals  structured  in  this  way  is  called  a  TRANS¬ 
ACTION  GROUP,  and  the  time  intervals  in  one  TRANSACTION  GROUP  are  referred 
to  as  TIME  SLOT  INDICES,  e.g.,  (Figure  3.5-5),  the  MU  transmits  in  Time 
Slot  Index  (TSI)  #0,  the  first  inbound  transmission  is  in  TSI  #6,  etc. 

Since  no  Unit  is  allowed  to  be  more  than  four  links  (levels)  away  from 
the  MU  in  order  to  specify  where  in  a  TRANSACTION  GROUP  a  Unit  operates, 
we  need  to  specify  only  the  level  of  the  Unit's  associated  time  intervals. 

Since  all  transaction  groups  have  the  same  pattern  of  transmissions, 
given  the  level ,  we  know  exactly  which  time  intervals  within  a  transaction 
group  a  unit  uses  for  transmitting  and  which  for  receiving.  Hence  the 
Network  Manager  can  ignore  the  internal  structure  of  the  transaction 
groups  and  need  only  know  the  (1)  the  level  of  the  time  intervals  to 
which  a  unit  is  assigned,  and  (2)  which  transaction  group  they  are  in. 

How  is  the  latter  specified?  This  involves  the  second  aspect  of  the 
organization  of  time  which  the  Network  Manager  can  ignore,  because  al¬ 
though  complex,  it  is  fixed.  Logical  Time  is  mapped  into  real-world 
time  in  a  complex  way.  If  we  take  all  the  time  intervals  in  a  frame 
(128)  and  arrange  them  in  a  rectangle  (or  a  box,  if  we  have  operations 
at  different  frequencies)  so  that  the  transaction  groups  are  vertical 
columns  (Figure  3.5-5),  then  we  can  unwind,  or  scramble,  these  Logical 
Time  intervals  into  real  time  in  some  random  way  for  security  purposes. 

This  latter  scrambling  can  be  ignored  entirely  by  the  Network  Manager. 
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Time  Slot  Indices  Comprising  a  Transaction  Group 


In  the  representation  of  a  Frame  as  a  box  or  rectangle,  however,  the  trans¬ 
action  groups  are  the  columns,  and  as  such  can  be  assigned  numbers.  Now 
we  will  make  it  a  requirement  (as  does  Hughes)  of  our  system  that  in  each 
of  the  256  frame  "boxes,"  or  "rectangles,"  that  a  column  with  the  same 
number  represents  a  transaction  group  (PORT  Path)  from  the  same  tree 
(network).  If  we  now  imagine  the  256  Frame  boxes  all  lined  up  linearly 
in  an  epoch,  and  consider,  say,  column  #35  in  each  box,  a  neon  flash 
in  that  column  will  correspond  to  a  neon  flash  up  and  down  some  (dif¬ 
ferent)  PORT  Path  in  the  same  tree  (network).  So  now  if  we  know  the 
level  and  tree  number  (i.e.,  which  column  number  within  a  frame/box), 
all  that  remains  to  specify  when  a  UU  operates  is  to  say  which  frames 
it  operates  in.  But  since  the  transmissions  along  the  PORT  Paths  are 
cyclic  (e.g.,  every  4  frames),  all  we  need  to  specify  is  the  Period 
(Per)  and  the  Start  Frame  (SF). 

Thus  these  four  numbers  completely  and  exhaustively  specify  which  Logical 
Time  intervals  a  UU  operates  in:  Period  and  Start  Frame  are  sufficient 
to  tell  which  frames  a  unit's  transaction  group  (PORT  Path)  is  assigned 
to  operate  in,  the  Tree  Number  (TN)  tells  which  column  of  time  intervals 
(Transaction  Group)  in  each  frame,  and  Level  (Lev),  as  explained  above, 
determines  which  time  intervals  (TSI's)  within  a  column  of  time  intervals 
(Transaction  Group). 

Hence  we  can  think  of  a  UU's  PORT  Link  Assignments  as  assignments  to  oper¬ 
ate  at  a  particular  Logical  Time,  specified  by  these  four  integers  (c.f.. 
Figure  3.5-6): 

t  =  (Exp. ,  Lev,  TN,  SF)  (3) 

Since  the  data  format  in  the  documentation  [14]  only  allows  3  bits  to 
specify  period,  it  must  be  the  exponent  (i.e.,  2ex^  =  Per),  not  the  period 
itself  (Figure  3.5-7)  that  is  used  to  specify  a  Logical  Time.  This  fact 
is  reflected  in  the  specification  of  cur  data-type  Logical  Time,  as 
indicated  in  Figure  3.5-8  .  We  can  then  define  Per(t)  as  a  non-primitive 
operation. 
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Exp  (t) 


de.6uuju.cn  cu> 
a  eontn.cZ  map 


OPERATION:  p=Per(t); 


WHERE  p,t  ARE  NATURALS; 


DATA  TYPE:  Logical  time  (of  M) ; 

PRIMITIVE  OPERATIONS: 

integer  =  Exp (t) ; 
integer  =  Lev(t) ; 
integer  =  TN(t) ; 
integer  =  SF(t) ; 
boolean  =  Teq? (tj ,t2) ; 

AXIOMS: 

WHERE  Tm  IS  A  CONSTANT  SET  OF  Logical  times; 

WHERE  tu  IS  A  Tu; 

“  n 

WHERE  ttt,,t_  ARE  Logical  times  AND  ARE  NOT  T  - 
12  M 

111  0  <  Exp(t)  <  7; 

[2]  -1  <  Lev (t )  <  3; 

[3]  0  <  TN  (t)  <  63; 

[4J  0  <  SF(t)  <  255; 

[5]  (Exp (t 1 )+l  =  Exp(t2))  =  (SF(t2)  -  SF(t1)  =  2Exp^tl^"1; 

[6]  Exp(tM)  =  0; 

[7]  0<TN(tM)<64; 

[8]  Lev(tM)  =  -1; 

[91  SF(tM)  =  0; 

[10]  Teq? (t i , t2)  =  AND (Exp (t ^ )  =  Exp(t2), 

Lev(t1)  =  Lev(t2), 

TN  (t 1 )  =  TN(t2), 

SF(t1)  =  SF(t2)  mod  Per(t1)): 

END  Logical  time; 
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More  importantly,  now,  we  need  ask,  what  properties  do  Logical  Times  have 
which  will  be  useful  to  us  in  specifying  the  system?  We  remember  that 
there  was  a  rough  intuitive  notion  of  one  UU  supporting  another  UU,  which 
we  tried  to  formalize  {by  axiomatizing ) .  When  one  UU  supports  another 
along  a  PORT  Path,  however,  the  time  slots  which  correspond  to  the  links 
also  stand  in  a  particular  relation  to  one  another,  namely  they  follow  one 
another  successively  in  a  transaction  group  of  Logical  Time  intervals. 

But  this  is  a  strictly  numerical  relationship,  and  easy  to  check  auto¬ 
matically;  this,  this  should  be  our  basic  relationship,  and  support  be¬ 
tween  UUs  dependent  upon  whether  their  assigned  time  slots  are  adjacent. 

To  make  this  clear,  we  have  separated  the  two  meanings  of  "SUPPORT": 
U-support  (between  UUs)  and  T-suoport  (between  Logical  Times). 

This  distinction  is  extremely  important,  because  the  two  behave  quite 
differently.  The  Logical  Time  intervals  always  "exist"  and  stand  in  the 
same  relation  to  one  another  regardless  of  whether  or  not  some  UU  is 
designated  to  operate  in  them.  Thus  if  t^  and  t^  stand  in  the  relationship 
such  that  tj  T-supports  t^,  we  will  say  Tsupp?(tj,t2)  =  TRUE  regardless 
of  whether  or  not  they  have  UUs  assigned  to  them  by  the  PORT  Link  Assign¬ 
ment  function  (PLA).  This  can  be  determined  solely  from  the  primitive 
operations  on  t.'s,  such  as  Exp(t),  etc.,  as  shown  in  the  definition  of  the 
operation  Tsupp?  in  the  data-type  specification  (Figure  3.5-9). 

3.6  U-support  vs  T-suoport 

We  are  now  in  a  position  to  say  explicitly  how  to  answer  the  question, 

"does  U,  U-support  U;?"  computationally.  Usupp?(u^  ,u2)  =  TRUE,  if  and 
only  if  one  of  the  t's  assigned  by  PLA  to  u^  happens  to  T-support  one 
of  the  t's  assigned  to  -LA  to  u2-  That  is,  suppose  for  a  moment  that 
Uj  and  u7  'nave  only  or.e  FORT  Link  Assignment  each  instead  of  two: 
ta  =  PLAluj)  and  tfa  =  ?LA(u2).  Then  if  Tsupp?( tfl ,tb)  =  TRUE,  we  know 
that  US'jpp?(uj,u2)  =  T-.L'E  as  well.  Since  Tsupp?  is  defined  by  computable 
functions,  we  would  knew  exactly  how  we  can  answer  the  question  Usupp? 
in  ot  •  c  -eg ram  should  it  arise. 

Unfortunately,  because  cf  the  reouired  duplexing,  things  are  not  this 

3 

simple.  For  many  good  operational  reasons  ,  it  is  necessary  for  each 
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OPERATION: 

WHERE 

Tsupp?  (  t1 

END  Tsupp? 


boolean  =  Tsupp?  (  t2  ) 
t2  ARE  Logical  Times; 


t2  )  =  (  Exp  (t^ )  _> 

(  Lev  (t^ )  < 
(  TN(t1)  = 
(  SFft,)  = 


Exp(t2)  )  £ 

Lev (t2)  )  £ 

TN(t2)  )  £ 

SF(t„)  mod  Per( 


Figure  3.5-9 
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UU  to  have  not  one,  but  two  PORT  Link  Assignments;  that  is,  PLA(u)  = 
(ta>tb),  a  duple.  (Leaving  aside  the  behavior  of  the  MU,  which  we  con¬ 
sider  later.)  So  while  the  inverse  of  the  PLA  mapping  (ALP)  is  single 
valued  (ALP(t)  =  u;  there  is  only  one  UU  assigned  to  a  Logical  Time), 

PLA  itself  is  two-valued,  and  the  question  "what  is  the  PLA  of  U^?" 
is  meaningless,  since  there  are  two,  and  we  must  at  all  times  know  which 
one  we  are  referring  to.  (We  will  see  later  how  this  causes  problems 
when  we  look  at  some  of  the  proposed  tests  in  the  search  algorithm  in 
the  Control  Map. ) 

This  affects  our  calculation  of  Usupp?  If  PLA(u^)  equals  (ta>tb)  and 
PLA(u2)  equals  (tc,td),  then  Usupp?(u^  ,u2)  is  true,  if  either  Tsupp? 

(ta,tc)  £r  Tsupp?(ta,td)  or  Tsupp?(tb,tc)  or  Tsupp?(tb,trf)  are  true! 

In  other  words,  if  we  want  to  ask,  as  part  of  some  test  in  the  Network 
Manager  module,  if  one  UU  supports  another,  we  may  have  to  try  all  four 
possibilities  (Figure  3.4-1,  Axiom  6b).  Note  the  difference  in  com¬ 
plexity  between  Axiom  6b,  which  is  stated  in  terms  of  PLA,  and  Axiom  6a, 

4 

which  is  stated  in  terms  of  the  inverse  function,  ALP  .  Because  of  this 
we  will  always  want  to  try  to  state  our  algorithms,  if  possible,  in  terms 
of  the  Logical  Time  relations,  rather  than  UU  relations,  since  UU  relations 
will  have  to  be  translated  back  into  Logical  Time  relations  to  be  cal¬ 
culated  anyway,  and  the  translation  is  anything  but  straightforward. 

We  will  examine  this  more  carefully  when  discussing  the  Control  Map 
for  tf  °  PLA  Control  submodule. 

3.7  Logical  Time  Axiom  #5 

Returning  briefly  to  the  specification  for  the  data  type  Logical  Time, 
there  are  two  points  which  deserve  further  comment.  First  is  the  rather 
strange  and  complex  looking  Axiom  5  (Figure  3.5-8).  What  this  says  is 
that  there  is  no  optional ity  in  dividing  up  unassiyned  (available)  Logical 
Times,  but  rather  that  they  are  structured  according  to  a  particular 

5 

pattern.  For  example,  suppose  in  Figure  3.7-1  that  all  the  time  inter¬ 
vals  marked  by  little  circles  were  available  for  assignment^ .e. ,  not 
assigned  to  a  UU:  ALP(t)  =  REJECT).  Then  there  is  no  a  priori  logical 
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reason  why  we  could  not  divide  them  up  as  follows:  as  two  possible 
Logical  Times  available  for  PORT  Link  Assignments: 


Per  Lev  TN  SF 

V  ^  x  y  ^  (level  and  tree  given 

/o  y  v  n  as  x  and  y  since  they 

u2'  v  y  1  are  not  relevant  to  this 

discussion) 

Alternatively,  another  logically  possible  division  would  be  to  have 
four  possible  logical  times  with  periods  of  4: 

t1:  (4  x  y  0) 

t2:  (4  x  y  1) 

t3:  (4  x  y  2) 

t4:  (4  x  y  3) 


Or  three  logical  times  for  possible  PORT  Link  Assignments  with  different 
periods: 


•V  (2  x  y  0) 

t2:  (4  x  y  1) 

t3:  (4  x  y  3) 

There  are,  of  course,  many,  many  more  possibilities,  even  for  this  16- 
frame  epoch,  and  enormously  more  for  a  real  256-frame  epoch.  However, 
as  far  as  we  can  determine  (c.f.  [14)  pp.  3.5-18/19),  the  actual  PLRS 
program  divides  them  up  by  a  standard  algorithm:  begin  with  the  logical 
time  having  the  lowest  possible  start  frame  and  lowest  possible  period, 
call  it  t, ;  take  the  next  lowest  start  frame  and  next  lowest  possible 
period  among  the  remaining  available  logical  times  (Lev  and  TN  being 
held  constant),  and  call  that  t^;  from  the  remaining  logical  times  choose 
the  next  lowest  start  frame  and  next  lowest  period  for  t^,  and  so  on. 

Thus  from  the  unassigned  logical  times,  we  always  get  the  same  "mix" 
of  possible  PORT  Link  Assignments,  as  represented  by  the  t^,t2,tj,t4 
actually  shown  in  Figure  3.7-1. 
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It  should  be  remarked,  incidentally,  that  we  wondered  whether  this 
could  possibly  have  been  left  as  a  user  option:  to  vary  the  mix  of  logical 
times  (possible  PORT  Link  Assignments)  at  different  rates  (periods), 
depending  on  the  mix  (ratio)  of  airborne,  manpack,  and  other  units  in 
a  division.  Obviously  if  one  had  all  fast  rate  (low  period)  logical 
times  available,  one  would  have  less  total  possible  PORT  Link  Assignments, 
or  if  one  had  the  other  extreme,  all  slow  rate  (high  period)  logical 
times  there  would  be  many  more  possible  PORT  Link  Assignments.  One  would 
not  use  either  extreme,  just  as  one  does  not  turn  the  shower  on  al 1 
the  way  hot  or  all  the  way  cold,  it  is  helpful  to  be  able  to  adjust  the 
temperature. 

3.8  Other  Operations  on  Logical  Times 

Having  our  basic  specifications  of  the  data  types  UU  and  Logical  Time 
in  hand,  it  is  then  simple  to  define  additional  operations  on  those 
data  types  as  we  need  them  for  the  program.  For  example,  consider  some 
additional  operations  on  Logical  Time.  The  operation  Tsupp?  (Figure 
3.5-9)  tells  us  if,  for  any  two  Logical  Times,  one  supports  the  other. 

We  may  want  to  know  if  one  directly  supports  the  other— e.g.,  in  Figure 
3.8-1,  tj  supports  t-j,  but  it  does  not  directly  support  tg.  The  time 
interval  on  the  other  hand,  does  directly  support  tg.  It  is  a  simple 
matter  to  write  an  operation  which  tests  this,  as  shown  in  the  definition 
of  DTsupp?  in  Figure  3.8-2. 

Similarly,  we  find  in  doing  the  control  map  that  we  want  to  ask,  for  a 
particular  Logical  Time,  which  Logical  Time  it  is  supported  by.  This 
can  also  be  defined  from  previous  operations,  as  shown  in  Figure  3.8-3, 
Derived  Operation  DTsupp.  Note  the  difference  in  these  two  operations: 
the  first  asks,  given  two  times,  does  one  support  the  other;  the  other 
calculates  which  time  supports  the  one  already  given: 


boolean  =  DTsupp?(tj ,t2) 

(5) 

tj  =  DTsupp(t2) 

(6) 

We  will  see,  when  we  start  writing  the  specification  for  a  section 
o~  the  Network  Manager  that  we  actually  do  need  both  different  operations. 
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OPERATION;  boolean  =  DTsupp?  (t^t^) ; 

WHERE  t^,t2  ARE  Logical  times; 

DTsupp?  (t1  ,t2)  =  Tsupp?  (t1  ,t2)  AND  (LevCt^  +  l  =  Lev(t2)) 
END  DTsupp? 
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DERIVED  OPERATION:  t]  =  DTsupp(t2); 


WHERE  t1 ,t2  ARE  t's; 


DTsupp?(t1,t2)  =  (t 1  =  DTsupp(t2)); 


END  DTsupp; 


Figure  3.8-3 
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There  are  several  other  operations  defined  with  the  data-type  specifica¬ 
tions  (Figure  3.8-4).  Some  of  these  are  referred  to  as  needed  in  dis¬ 
cussing  the  control  map  for  FIND-PLA  (Section  4). 

3.9  Other  Data  Structures  in  the  Network  Manager 

It  should  be  noted  that  in  addition  to  the  data  types  Logical  Time  and 
User  Unit  that  were  specified  for  use  in  the  following  control  map,  there 
will  need  to  be  other  data  types  and  structures  specified  as  more  modules 
of  the  Network  Manager  are  completed.  For  example,  in  order  to  specify 
the  assignment  and  clean-up  modules  of  PLA  Control  as  well  as  the  various 
modules  making  up  the  preliminary  part  of  PLA  Control,  we  would  need  the 
data  structure  for  PORT  Link  Assignment  itself.  Intuitively,  this  could 
consist  of  a  tree-like  structure,  as  in  Figure  3.9-1: 


where  u.  is  some  User  Unit,  t-j  and  t ^  are  the  Logical  Times  such  that 
(t-jjtj/  =  PLA(u^)  and  f,  CR,  ...  are  various  parameters  associated  with 
the  particular  PORT  Link  Assignment  (u^,Uj),  such  as  whether  or  not  it 
is  FORCED,  it's  COMMAND  RELIABILITY,  etc.  Such  a  data  structure  would 
have  primitive  operations,  such  as: 

SAMPLE  PRIMITIVE  OPERATIONS  FOR  PLA: 

port-link-assignment  =  Assign(user-unit,  logical -time,  integer) 
port-1  ink-ass  ignment-|  =  Deassign(port-l  ink-assignment^, integer) 
user-unit  =  UU(port-l ink-assignment) 
logical-time  =  LT(port-l ink-assignment,  integer) 


Definition  of  ACTIVE  IN  SAME  FRAME: 

OPERATION:  boolean  =  AISF(trt2); 

WHERE  ARE  Logical  times; 

AS  I  F(t1 ,  t2)  =  OR'SF  (t  ^ )  =  SF(t2)  mod  Perft^, 

=  SF(t2)  mod  Per(t2)); 

END  AS  IF; 

Alternative  formulation: 

AISF(tt,t2)  =  (SF(t1 )  =  SF(t2)  mod  MIN(Per (t,) .Per (t2))) 


and  axioms  such  as: 


SAME  AXIOMS  FOR  PLA: 

WHERE  u  IS  A  User  Unit, 

(t^tg)  ARE  Logical  Times, 
k  IS  A  Natural , 

pla  IS  A  PORT  Link  Assignment; 

(1)  t  =  LT(Assign(u,t,k)),k); 

(2)  u  =  UU(Assign(u,t,k)); 

(3)  PLA(u)  =  (LT(Assign(u,t^ ,0) ,0,  LTCAssignfu.t^l  )1 )) ; 

(4)  ALP(t)  =  UU(Assign(u,t,k)); 

(5)  REJECT  =  LT(Oeassign(pla,k) ,k) ; 

(6)  u  *  UU(Deassign(pla,k) ,k) ; 

Clearly,  additional  axioms  would  be  needed,  depending  upon  design  con¬ 
siderations.  For  example,  if  we  wanted  the  assignment  module,  which 
follows  the  FIND-PLA  module,  to  simply  replace  a  Logical  Time  in  a  PORT 
Link  Assignment,  then  we  might  leave  the  assignment  axioms  as  they  are, 
since  Axiom  (1)  already  does  this;  if  we  were  to  insist  (for  whatever 
reasons)  the  desassignment  was  required  before  reassigning  a  new  Logical 
Time,  the  we  might  add  Axioms  (7)  and  (8): 

(7)  pla  =  Assign(u,t1 ,k); 

(8)  REJECT  =  Assign(u,t2,k) ; 

In  any  case,  it  would  be  to  this  data  structure  that  we  could  then  add 
additional  operations  and  accompanying  axioms  to  deal  with  such  parameters 
as  COMMAND  RELIABILITY  and  FORCED-PLA.  For  example,  suppose  we  wanted 
to  indicate  whether  or  not  a  PLA  was  forced.  We  could  then  add  the  primi¬ 
tive  operations: 

SAMPLE  PRIMITIVE  OPERATIONS  FOR  FORCED-PLA 

Rforce(port-l ink-assignment,  integer)  =  port-link  assignment; 
Rforced?(port-l ink-assignment,  integer)  =  boolean 
Unforce(port-l ink-assignment,  integer)  =  port-link-assignment; 

and  accompany  them  with  axioms,  such  as: 


SAMPLE  AXIOMS  FOR  PRIMITIVE  OPERTIONS  FORCED- PLA 


Rforced?(Rforce(pla,k) ,k)  =  True; 

Rforced?(Unforce(pla,k) ,k)  =  False; 

Note  that  we  need  each  time  we  refer  to  a  unit's  PORT  Link  Assignment 
structure,  we  need  to  include  the  integer  which  indicates  whether  it  is 
the  first  or  second  assignment  (pairing  of  the  u  and  some  t)  that  is  being 
referred  to.  This  issue  is  also  discussed  in  Section  4. 2. 3. 3  in  this  re¬ 
port.  We  could  get  around  this  by  defining  our  data  type  Logical  Time 
differently;  that  is,  adding  the  concept  of  assignment  of  parameters 
directly  to  the  data  type  Logical  Time: 

SAMPLE  ADDED  PRIMITIVE  OPERATIONS  FOR  DATA  TYPE  LOGICAL  TIME: 

logical-time  =  Assign(user-unit,  logical -time) ; 
logical-time  =  Deassign(logical-time) ; 
logical-time  =  Rforce(logical-time) ; 
logical-time  =  Unforce(logical-time) ; 
boolean  =  Rforced?( logical -time) ; 

with  the  corresponding  axioms: 

SAMPLE  ADDED  AXIOMS  FOR  ABOVE  PRIMTIIVE  OPERATIONS: 

WHERE  u  IS  A  User  Unit, 

t  IS  A  Logical  Time; 
u  =  ALP(Assign(u,t) ) ; 

REJECT  =  ALP(Deassign(t)) ; 

Rfcrced?(Rforce(t))  =  True; 

Rforced?(Unforce(t) )  =  False; 

While  this  is  clearly  more  elegant  mathematically^  than  the  separate 
data  structure  for  PORT  Link  Assignment,  it  leaves  us  with  the  problem, 
discussed  elsewhere  in  this  report  (Section  3.6)  of  not  being  able 
to  reference,  or  address,  a  particular  PORT  Link  Assignment  of  a  UU, 
ot.ner  than  to  give  the  specification  of  the  Logical  Time  involved.  That 
is,  as  we  shall  see  in  Section  4,  the  FIND-PLA  control  map,  tests  are 
ccnoir.ually  being  proposed  which  refer  to  UUs,  and  there  is  no  way  (given 
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this  latter  specification  for  Logical  Time)  to  refer  to  a  UU's  PORT  Link 
Assignment,  since  we  still  have  PLA(u)  =  ( t-j , t2 )  and  so  there  are  two. 
The  former  solution,  to  have  a  separate  data  structure  for  PORT-Link- 
Assignment,  including  a  reference  integer,  is  considerably  more  clumsy. 
In  view  of  the  necessity  for  duplexing,  this  is  a  problem  which  deserves 
more  study. 

Those  operations  would  then  in  turn  be  used  to  specify  the  FORCE-PLA 
module.  Similarly,  other  modules  such  as  Suggest  PLA  and  Check  Command 
Rel iabil ity,  could  be  specified,  adding  operations  and  axioms  in  this 
fashion. 
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4.0  THE  FIND-PLA  MODULE 


4. 1  Identification  of  Submodules 

Let  us  now  turn  to  the  control  map  of  the  Network  Manager.  Although 
we  made  a  rough  preliminary  control  map  (following  the  Hughes  docu¬ 
mentation)  in  the  preliminary  stages  of  our  investigation,  this  only 
covered  in  a  general  wa y  the  first  three  or  so  levels  of  detail  (com¬ 
pare  Figure  2.2-4  and  Figure  4.1-1).  In  order  to  show  clearly  how  a 
fully  worked-out  HOS  specification  including  control  map  and  accom¬ 
panying  AXES  statements  would  look,  we  decided  to  restrict  our  attention 
for  the  purposes  of  this  example  to  the  most  complex  and  interesting 
submodule,  PLA  Control.  PLA  Control  module  is  not  really  decomposed 
in  the  Hughes  PPS  in  great  detail  with  respect  to  its  submodules,  but 
there  are  descriptions  of  some  of  its  main  functions.  We  can  safely 

assume  that  there  are  at  least  three  major  submodules:  (1)  the  one 
/ 

which  designates  a  particular  PORT  Link  Assignment  for  replacement; 

(2)  the  search  algorithm  itself,  which  finds  a  new  Logical  Time  for 
possible  PORT  Link  Assignment  to  a  given  UU;  and  (3)  a  housekeeping, 
or  clean-up,  module  which  takes  care  of  rearranging  the  rest  of  the  net¬ 
work  once  the  new  PORT  Link  Assignment  has  been  made  (e.g.,  changing 
the  assignments  of  UUs  supported  by  the  UU  whose  PLA  was  changed,  sending 
the  change  to  the  CLA-Control  module  so  that  CROSS  Link- Assignments 
can  also  be  corrected,  and  so  on). 

Under  the  suggested  Hughes  module  PLA  Control,  we  further  restricted 
our  attention  to  one  submodule,  so  as  to  demonstrate  what  a  completed 
specification  would  look  like.  (A  module  is  completely  specified  when 
all  of  the  functions  have  been  related  by  control  structures  and  defined 
down  to  the  point  of  primitive  operations  on  defined  data  types.  Of 
course  non-primitive  operations  and  control  structures  may  be  used,  j_f 
they  have  been  specified  separately.)  The  module  chosen  was  the  search 
algorithm  in  submodule  (2),  FIND-PLA.  It  is  related  roughly,  as  shown  in 
the  n-.'t?cthetical  control  map  (Figure  4.1-1).  The  dotted  lines  indicate  our 
best  hypothesis  as  to  how  the  system  would  relate  these  various  modules. 
Since  the  operator  system  is  discussed  only  sketchily  in  the  PPS,  there 
was  not  really  enough  information  to  make  more  than  an  educated  guess 
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at  this.  To  specify  this  completely  would  require  more  extensive  dis¬ 
cussion  with  the  designers  at  Hughes.  Hence  we  have  shown  in  this  part 
of  the  control  map  only  some  main  submodules  without  indicating  inputs 
or  outputs  (also  partially  because  of  the  difficulty  in  determining 
these  from  the  information  available,  as  discussed  in  Section  2). 

In  view  of  the  complexity  of  the  specification  for  the  FIND-PLA  mdoule 
and  the  similarity  of  the  AXES  statements  accompanying  the  control  map 
to  coding  in  various  higher-order  languages,  it  should  be  reiterated 
here  and  emphasized  that  this  is,  of  course,  NOT  code,  but  specification 
it  is  implementation  independent,  even  to  the  point  of  not  specifying 
exactly  hOW  the  sets  of  Logical  Time  are  to  be  stored  or  referenced 
(e.g.,  lists,  arrays,  etc.)  but  rather  as  any  kind  of  ordered  set,  leav¬ 
ing  it  up  to  the  programmer  to  decide  how  the  searches  might  be  most 
efficiently  conducted;  this  specification  simply  states  which  tests 
h 5  vp  "to  he  c n n • : •" '  — :  * 

It  should  also  be  remarked  that,  as  a  pilot  project  and  kind  of  peda- 
logical  example  of  HOS  specification  techniques,  this  particular  ver¬ 
sion  of  the  control  map  for  FIND-PLA  is  not  to  be  construed 
in  any  way  as  final  or  "the  last  word,"  but  rather  as  a  tool  for  making 
the  assumptions  about  the  program  specification  very  explicit  so  that 
they  can  more  easily  be  examined  and  revised. 

4.2  FIND-PLA  Control  Map 

4.2.1  The  Top  Level  of  FIND-PLA 

The  section  of  the  PPS  which  roughly  corresponds  to  the  FIND-PLA  module 
is  in  Section  3. 4. 2. 2. 2. 3  on  page  3-34,  "PORT  link  assignment  selection" 
[11]  (Figure  4. 2. 1-1).  Much  of  the  information  needed  to  complete 
the  specification  of  this  submodule,  of  course,  is  not  found  in  this 
section,  but  is  either  elsewhere  in  the  PPS,  in  the  STD,  implicit  in 
some  of  the  discussion,  or  even  absent  entirely.  In  the  latter  case, 
we  have  tried  to  make  reasonable  hypotheses  about  what  the  system  would 
do  in  order  to  complete  the  specification.  Also  there  is  a  fair  amount 
of  redundant  or  unnecessary  information  in  Section  3. 4. 2. 2. 3  [11]  which 
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3. 4. 2. 2. 2. 3  PORT  link  assignment  selection.  PORT  link  assignment  selection 
shall,  unless  requested  otherwise,  determine  the  best  match  between  UU  desired  PL 
states  and  available  PLAs.  Available  PORT  link  assignments  shall  be  determined 
from  the  unassigned  PLAs  directly  supported  by  active  UUs.  When  no  PLA  is  available 
for  assignment  to  a  UU  designated  for  PL  state  change,  that  UU  shall  be  requested 
to  demand  entry.  The  PLA  selection  criterion  and  PLA  restrictions  are  defined  in 
the  following  subparagraphs . 

3. 4. 2. 2. 2. 3.1  PLA  selection  criterion.  The  best  match  between  the  desired  PL 
state  and  the  available  PLAs  shall  be  selected  using  the  following  order: 

a.  PLA  with  an  exact  match  between  the  desired  and  available  rate 

b.  PLA  where  the  desired  rate  is  lower  than  the  available  rate 

c.  PLA  where  the  available  rate  is  lower  than  the  desired  rate 

For  otherwise  identical  PLAs,  selection  shall  be  made  in  the  following  preference 
order : 

d.  PLA  with  lower  levels 

e.  PLA  with  a  closer  rate  match  to  the  desired  rate 

f.  PLA  with  earlier  start  frames. 

3. 4. 2. 2. 2. 3. 2  PORT  link  restrictions.  Available  PLAs  shall  not  be  considered 
for  assignment  if  the  PLA  either  is  supported  by  a  UU  that  already  cooperates  in  a 
PLA  with  the  specified  UU,  or  is  active  in  frames  that  coincide  with  the  specified 
UU's  other  assigned  PLA.  Whenever  the  MU  is  the  supporting  unit  of  an  available 
PLA,  all  unassigned  A-level  PLAs  shall  be  considered. 

Each  PLA  shall  be  supported  by  only  one  UU.  No  two  UUs  shall  have  the  same 
PLA.  A  PLA  previously  assigned  to  a  UU  shall  not  be  available  for  reassignment  until 
its  deassignment  or  replacement  has  been  explicitly  acknowledged  by: 

a.  A  PLA  command  acknowledge 

b.  *  mode  command  acknowledge 

c .  l"J  t  ime  out . 

The  A-level  PLAs  shall  be  assigned  to  different  trees  until  all  allocated  trees  have 
been  used  at  least  once. 


Figure  4.2. 1-1 
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does  not  pertain  to  the  search  algorithm.  All  of  this  will  be  discussed 
after  a  walk  through  the  control  map  for  FIND-PLA  with  cormientary  on  its 
various  sections. 


Note  again  Figure  4.1-1,  which  shows  roughly,  without  indicating  inputs 
and  outputs,  how  FIND-PLA  is  related  to  some  of  the  other  Network  Manager 
functions.  Various  functions  such  as  UU  rate,  Suggest  PLA,  or  Monitor 
can  request  a  new  Logical  Time  for  PORT  Link  Assignment  by  outputting 
Told  t0  FIND-PLA;  FIND-PLA  then  outputs  a  new  Logical  Time,  tnew  to  the 
PORT  Link  Assignment  module  and  clean-up  module,  which  changes  the  PLAs 
of  the  UUs  supported  by  u^  via  t 

Let  us  focus  our  attention  on  the  top  level  of  FIND-PLA,  shown  in  Figure 
4. 2. 1-2.  The  inputs  to  FIND-PLA  are: 

p  (the  recommended  Period  (i.e.,  1/cycle  rate)  (c.f.  Footnote 
No.  2. 

tQid  (the  Logical  Time  of  the  PLA  designated  for  replacement) 

T  (the  set  of  possible  Logical  Times) 

(the  set  of  communicants  of  the  Ui  which  is  assigned  to  t  ^) 

The  top  level  consists  of  just  the  main  SEARCH  submodule  and  the  ERROR 
RECOVERY,  which  simply  says  to  output  a  new  Logical  Time,  t'N^w,  if  one 
is  found,  and  output  the  old  one,  tQLp,  if  SEARCH  does  not  find  a  new 
Logical  Time  for  PORT  Link  Assignment,  i.e.,  if  t'^  =  REJECT.  In 
each  case,  provision  is  made  for  an  appropriate  I/O  message  to  be  output  . 
Note  that  the  FIND-PLA  module  does  not  make  PORT  Link  Assignments!  What 
it  does  is  to  find  a  Logical  Time  which  is  appropriate  for  assignment  to 
a  given  UU,  which  would  either  replace  an  old  assignment,  or  in  case  of 
*CLD  =  REl^CT  (i-e->  the  uu  has  no  PLAs),  could  be  an  initial  assignment. 
In  ether  words,  this  module  simply  determines  that  a  particular  Logical 
Ti~e  meets  certain  specified  requirements  and  is  therefore  appropriate 
to  be  used  for  a  new  PORT  Link  Assignment.  The  actual  assignment  would 
be  cone  by  the  CLEAN-UP  or  housekeeping  module  of  PLA-Control ;  the  new 
Locoal  Time,  t.,rM>  and  The  given  UU,  u.,  would  be  inputs  to  the  CLEAN-UP 

I  1  t  M  I  Q 

module,  which  would  not  only  replace  tQLD  by  tN£W  ,  but  also  replace  the 
Logical  Times  of  the  PLAs  of  any  other  UUs  supported  by  u... 


81 


T 


Now  the  search  algorithm  itself  is  shown  in  Figure  4. 2. 1-3.  Before 
going  through  the  various  stages  in  detail,  it  would  help  to  have  an 
intuitive  understanding  of  how  it  is  done,  as  well  as  some  comments 
about  assumptions  we  have  made.  First  of  all,  the  way  we  assume  the 
search  is  conducted  is  illustrated  in  Figure  4. 2. 1-4.  The  basic  idea 
is  to  start  out  with  a  (perhaps  large)  set  of  Logical  Times  which  could 

be  possible  candidates  for  PORT  Link  Assignment  to  the  UU,  u.;  by  means 

of  the  various  tests  and  requirements  imposed  by  Section  3. 4. 2. 2. 3  of  the 
PPS  and  elsewhere  in  the  Hughes  documentation  to  whittle  down  the  set 
of  possible  candidates,  throwing  out  the  ones  which  are  illegal  for  one 
reason  or  another  until  there  remains  a  set  containing  only  one  unassigned 
Logical  Time,  t'NEW,  which  will  be  the  best  match  possible.  That  is, 

in  terms  of  Figure  4. 2. 1-4,  one  starts  out  with  a  large  number  of  candi¬ 

date  Logical  Times  for  PORT  Link  Assignment,  the  set  T,  and  after  various 
tests  and  eliminations  (the  double  arrows),  one  ends  up  with  a  single 

tNEW‘ 

It  turns  out  that  there  is  one  "hitch"  in  this  otherwise  very  straight¬ 
forward  process.  For  each  particular  UU,  u^  we  only  allow  those  Logical 
Times  which  are  T-supported  by  Logical  Times  which  happen  to  be  PORT- 
Link-Assigned  to  other  communicants  of  u-.  (Figure  4. 2. 1-5).  Note  that 
the  result  of  the  new  PORT  Link  Assignment  is  to  have  ui  U-supported 
by  a  different  UU  than  the  one  which  U-supports  it  currently.  Thus, 
although  the  bulk  of  our  tests  on  possible  Logical  Times  are  stated 
in  terms  of  conditions  on  Logical  Times,  we  have  to  refer,  at  least 
initially,  to  the  UU's  which  are  communicants  of  (i.e.,  those  which 
u.j  has  heard  from  at  some  time,  indicating  they  are  within  radio  range). 
This  is  shown  schematically  in  Figure  4. 2. 1-5.  Suppose  all  the  boxes 
in  the  top  row  (T|jrr ssianed^  rePresent  unassigned  Logical  Times  (which 
are  therefore  possible  candidates  for  PORT  Link  Assignment  to  u^).  We 
can  only  choose  the  ones  which  are  T-supported  by  Logical  Times  which  are 
PORT-Link-Assigned  to  one  or  another  of  u^'s  various  communicants  (UU's  in 
the  set  Ci ) .  But  this  is  not  a  case  of  simple  matching  up,  since  each 
comma;: icant  UU  in  has  two  PLA's  because  of  duplexing.  Therefore, 
or.e  nas  two  alternatives: 
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Search  (p,U|  ,lo|d 


(1)  to  find  all  the  Logical  Times  associated  with  the  UU's  in 

C.j,  find  which  further  set  of  Logical  Times  these  Logical  Times  T-support, 
then  find  which  of  those  are  unassigned,  i.e.,  available  for  assignment. 

(2)  to  find  the  unassigned  Logical  Times,  see  which  Logical  Times 
T-support  them,  then  eliminate  all  those  which  are  not  PORT-Link-Assign- 
ments  of  the  u^'s  communicants,  . 

Either  way  is  round-about,  but  the  second  seems  to  involve  less  computa¬ 
tion,  so  we  have  opted  for  (2).  Thus,  in  Figure  4. 2. 1-5,  we  first  find 

TUnassigned’  the  top  row  of  boxeSi  then  we  find  Supporting  (al1  the 
boxes  in  the  bottom  row,  which  represent  the  Logical  Times  that  support 

TUnas signed*  We  then  iminate  a^  the  Logical  Times  not  assigned  to 
some  communicant  of  u^ ,  (the  dotted  boxes)  being  left  with  the  boxes 
labeled  t  or  t^.  (We  also  need  to  treat  possible  A-level  assignments 
differently  than  other  levels.  This  has  been  shown  by  separating  the 

A 

T  into  those  which  are  assigned  to  the  Master  Unit  and  those  which  are 
assigned  to  other  user  units;  we  wait  until  later  in  f^  to  actually 
separate  out  the  T's  which  have  Lev(t)  =  0). 

We  then  need  to  find  the  set  of  Loqical  Times  which  are  both  unassiqned, 

A 

and  supported  by  the  Tr  .  This  gives  us  the  Logical  Times  indicated 

by  the  shaded  boxes  in  the  top  row.  We  can  now  perform  all  the  tests 
and  matching  required  to  choose  one  which  will  be  the  t^^. 

4.2.2  The  Operations  SET-FUNCTION  and  SET-TEST 

Before  discussing  the  exact  statement  of  the  functions  in  the  control 

map  for  FIND-PLA,  we  need  two  additional  tools,  which  HOS  supplies  us 

with.  In  large  systems  (programs)  there  are,  of  course,  functions  which 

are  repeated  over  and  over,  and  we  may  wish  to  simply  define  them  in  one 

place  (especially  if  the  definition  is  complex)  to  be  invoked  whenever 

needed.  Similarly,  HOS  control  maps  and  accompanying  AXES  statements 

can  be  used  (aswe  have  seen  in  the  section  on  data  types)  at  the  specifi-  C 

cation  layer  to  define  operations  which  can  be  referenced  whenever  needed. 

C 
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In  addition,  just  as  there  may  be  repeated  functions,  there  may  also  be 
certain  control  structures  which  are  used  over  and  over  again,  but  with 
different  functions.  AXES  also  gives  us  the  capability  to  define  these 
as  needed  and  create  a  syntax  so  they  can  be  invoked,  employing  the 
function  needed  for  a  particular  case,  in  various  places  in  the  system. 
Examples  of  such  structures  are  cojoin  and  Coinclude,  which  are  already 
HOS  library  structures  (c.f.  Appendix  II). 

For  this  PLRS  module,  we  have  defined  two  structures  which  will  see  use 
repeatedly.  (They  are,  incidentally,  used  in  other  PLRS  modules,  and 
of  wide  general  application.  Because  of  their  general  applicability, 
they  will  be  added  to  our  library  of  AXES  structures.)  The  first  is 
called  SET- FUNCTION,  and  is  defined  in  Figure  4. 2. 2-1.  What  it  does 
is  to  take  as  input  any  set-like  data  type  (lists,  arrays,  files,  etc.) 
and  apply  some  operation  which  is  individually  valid  on  the  members 
of  the  input  set,  to  produce  an  output  set  of  the  same  dimensions  as  the 
input  set,  but  whose  members  are  of  whatever  data  type  is  normally  out¬ 
put  by  the  operation  chosen.  For  example,  suppose  we  take  the  operation 
y  =  sin(x),  which  takes  as  its  input  an  angle  and  outputs  the  sine  of  that 
angle.  But  suppose  that  our  input  data  will  consist  of  100  angles,  stored 
in  a  10x10  array.  Then  we  simply  write  Y  =  s i n [ X ]  with  square  brackets 
and  capital  letters.  If  X  is  the  10x10  array,  then  SET-FUNCTION  is  in¬ 
voked,  which  appl ies  .sin(x)  to  each  angle,  x.  .,  in  the  array  X,  pro- 

*  >  J 

ducing  a  10x10  array,  Y,  each  of  whose  members,  y.  . ,  is  the  sine  of  the 
corresponding  x-  ..  Since  we  are  continually  working  with  large  num- 

■  Jj 

bers  of  Logical  Times,  presumably  sorted  in  some  kind  of  ordered  set 
(list,  array,  etc.),  this  will  clearly  be  a  useful  control  structure 
f or  the  FliiD-PLA  module. 

Tne  other  necessary  control  structure  is  SET-TEST,  defined  in  Fig.  4. 2. 2-2. 
Inis  is  different  from  SET-FUNCTION,  which  really  transforms  one  set  into 
another,  in  that  the  output  is  always  a  subset  of  the  input.  What  it  does 
is  to  take  some  set  of  objects,  and  throw  out  all  those  which  don't  meet 
seme  test  or  criterion.  For  example,  if  we  had  a  large  set  of  Logical 
Times,  we  might  want  to  consider  only  those  whose  Period  was,  say,  less 
than  8.  Now  the  syntax  for  SET-TEST  is:  "T^  is  formed  froml^forall 
c'p.t; ',  where  T^  is  the  set  we  start  out  with,  and  T ^  is  the  set  we  have 
afte-'  eliminating  all  the  _t’s  in  for  which  the  boolean  function 
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where  T0,  T,  are  of  some  type 


Syntax:  T  is  formed  from  T.  for  all  g(p,t). 


g(p,t)  =  FALSE.  So  for  our  example,  we  could  say,  where  and  are 
some  kind  of  set  of  Logical  Times,  "T2  is  formed  fromTj  foraii  Per(t)  <  8." 
This  says  that  the  times,  t,  which  are  in  T^,  are  those  which  were  in 
Tj,  and  whose  period  was  less  than  8.  In  the  figures  in  this  report,  we  some¬ 
times  replace  the  words  "is  formed  by"  by  the  symbol  "c"  for  brevity. 

Notice  that  the  statement  "Per(t)  <  8"  corresponds  to  "g(p,t)"  in  the 
general  syntax  for  SET-TEST.  The  operation  £  is  really  any  (n+1)  place 
boolean  operation  (i.e.,  whose  value  is  either  TRUE  or  FALSE)  and  whose 
first  £  places  are  fixed-parameters  or  constants,  and  whose  (n+l)th 
place  is  the  variable  being  tested.  That  is,  g(p,t)  is  just  the  state¬ 
ment  of  some  possible  property  of  t ,  where  p  is  a  list  of  some  constant 
parameters  which  may  be  necessary  to  state  the  property,  e.g.,  "8"  in 
the  above  example. 

To  reiterate,  in  the  statement  "Per(t)  <  8,"  the  constant  8^  corresponds 
to  the  £  in  "g(p,t),"  and  the  compounded  operation  "Per(_)  <  _ "  cor¬ 
responds  to  the  "g  (_,_)".  This  is  perhaps  easier  to  see  in  prefix-notation 
than  in  infix-notation:  "<  (Per(t) ,8)- 4 10 

At  any  rate,  it  is  clear  that  if  we  are  to  begin  with  a  set  (perhaps  large) 
of  logical  times  which  are  possible  candidates  for  PORT  Link  Assignment 
and  find  a  single  "best"  candidate  by  throwing  out  all  those  which  don't 
meet  certain  criteria,  then  this  SET-TEST  structure  will  be  the  basis 
for  this  module.  Once  we  have  defined  these  two  structures  for  working 
with  sets,  then  it  is  simply  a  matter  of  trying  to  state  the  tests  and 
criteria  to  be  used  correctly,  and  in  the  correct  order. 

4.2.3  The  Search  Algorithm 

Now  that  we  have  these  two  structures  which  can  be  invoked  at  will  to 

either  perform  an  operation  on  a  set  or  to  perform  a  test  on  a  set,  let 

us  look  again  at  the  search  algorithm  (Fig.  4. 2. 1-3).  The  function  names 

f.  -f_  and  f  -  f.  are  used  to  save  space  and  are  abbreviations  for  the 
0  o  a  6  _ 

full  specifications  written  out  in  Figure  4. 2. 3-1. 

The  first  function,  fQ,  takes  the  set  of  all  possible  Logical  Times 
as  input  and  yields  the  ones  which  are  unassigned  as  output.  It  simply 
applies  the  function  ALP  (the  inverse  of  PLA,  PORT  Link  Assignment) 
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fn :  T  .  ,  cT  forall  Reject  =  ALP(t) 

0  unass i gned  — 


f ,  :  T 

I  supporting 


^2"  Tc.  —  ^"supporting  forall  Element? (APL(t) ,C. ) 


=  DTsupp  [T  .  .1 

ing  L  unass  igned-J 


f,:  T  C  T  .  ,  OR  (DTsupp? ([T  ],t)) 

3  c.  —  unassigned  c. 


f,  :  (T..T  )  =  f,  (T  )  SEE  BELOW  FOR  DETAILS 

4  A  c._A  H  c. 


f  :  T'.  =  f  (T.l  SEE  Fiqure  4.2.3.2-lb 

a  A  a  A  - 3 - 


f  :  T 1  =  f _ (T  )  SEE  Figure  4.2. 3.3-1 

B  C i -A  6  C i -A 


f  :  Operation:  c?|  forall  NOT  (Al  SF  (Other  (u .  ,tQ^)  ,t) ) 

where  T^ ,T^  are  sets  of  logical  times;  u.  is  a  uu;  tQ]d,  t, 
are  logi’cal  times: 


f ^ :  Operation:  CH00SE(p,T)  SEE  Figure  4.2.3.4-1 


(TA'Tc.  >  "  VTC.> 

i  -A  i 


COINCLUDE 


Ta"  f5(V 


T  =  f,(T  ) 
C i  -A  6  Ci 


f^:  TA  C  T^  forall  Lev(t)  =  0 


f ,  :  T  c  T  forall  Lev(t)  >  0 
o  c .  .  —  c . 
i  -A  i 


Figure  4. 2. 3-1 


93 


to  each  _t  in  T,  and  if  it  is  not  assigned,  i.e.,  if  ALP(t)  f  y ,  for  some 
u^  then  ALP(t)  =  REJECT.  Thus,  all  this  function  has  to  do  is  find  the 
t's  such  that  ALP(t)  =  REJECT. 


4. 2. 3.1  Finding  Eligible  Logical  Times 


Remember  that  this  is  the  specification  layer,  not  the  implementation 
layer;  fQ  does  not  necessarily  say  how,  exactly,  PORT  Link  Assignments 
are  to  be  stored  or  referenced,  or  even  that  Tunassigned  must  *5e  ca^“ 
culated  by  going  through  the  list  of  all  logical  times  on  each  pass. 

At  the  implementation  layer,  for  example,  \|nass-jgnec|  might  be  stored 
in  some  temporary  memory  and  simply  updated  on  each  pass.  We  might 
even  want  to  revise  the  specification  and  make  fg  part  of  the  CLEAN-UP 
module,  i.e.,  input  "^assigned  to  F1ND-PLA  directly. 


Note  how  straightforward  such  a  change  would  be.  We  can  see,  in  the  control 
map,  exactly  which  input  variables  would  have  to  be  changed,  and  we  would 
get  a  new  output  variable,  ^unassigned  from  CLEAN"UP-  This  illustrates 
two  points:  (1)  a  property  of  HOS  specifications:  that  changes  in  the 
specification  are  relatively  easy  to  make  prior  to  implementation  because 
of  the  modularity  of  the  control  map  format;  and  (2)  a  property  of  the 
PLRS  system:  it  is  cyclic,  rather  than  strictly  linear;  i.e.,  the  output 

of  a  function  "late"  in  the  cycle  may  produce  an  output  which  serves  as 

one  of  theinputs  on  the  next  cycle.  For  example,  an  ordering  of  functions 
like  "fy,  fj,  f2>  fj"  might  have  the  same  effect  as  the  order  "f ^ ,  f^, 

f3,  fQ"  since  the  output  of  fQ  will  still  serve  as  the  input  to  on  the 

next  cyclic  pass  through  the  system.  This  is  a  matter  deserving  more 
attention  than  we  have  space  for  here,  but  since  ordering  is  treated  only 
implicitly  in  the  PPS  and  STO,  we  simply  note  it  as  an  issue  to  be  re¬ 
solved  . 


The  next  function,  f  1 :  Tsupport1ng  ■  DTsupp  CTllnasslgnecl]  simply  gives  us 
(c.f.  Fig.  4.2. 1-5)  from  the  unassigned  logical  times,  the  set  of  logical 
times  which  support  them  (bottom  row  of  time-slot  boxes  in  Fig.  4. 2. 1-5. 

We  then  ask,  via  f  ^  which  of  those  logical  times  are  PORT-Link-Assigned 
to  UU's  which  are  communicants  of  the  u^  whose  tg(  n  we  are  trying  to 


change.  That  is,  if  t  is  a  Logical  Time  in  the  bottom  row  (Tr  ..  ), 

s  Supporting' 

is  there  a  u  =  ALP(t  ),  such  that  u  is  also  a  member  of  the  set  of 

J  ^  ^  A  A 

communicants,  C-?  That  is  what  f0  states:  T-  is  formed  from  TP 

i  ^2  Ci  Supporting 

ioraii  Element?(ALP(t) ,C. ).  Note  that  the  condition  on  formation  of  the 

new  subset  is  a  compound  function;  this  could  have  been  written  out  in 
full  AXES  format  as  follows: 


Operation:  b  =  g ( ,t); 

Where  b  is  a  3oolean, 

C .  is  a  Set  (of  UUs), 

t  is  a  Logical  Time, 
u  is  a  UU; 

b  =  Element?(u,Cl- )  cojoin  u  =  ALP(t); 
end  g; 

The  format  "Element?(ALP(t) ,C^)  is  simply  an  abbreviation  for  an  AXES 
defined  operation. 

The  function  fg  then  asks  of  the  Logical  Times  in  the  top  row  (Tunassigned^ 
are  they  T-supported  by  a  Logical  Time  which  is  assigned  to  one  of  u^'s 
communicant's?  (c.f.  Figure  4. 2. 1-5).  That  is,  it  eliminates  from 
TUnassigned  a11  the  L(59lcal  Times  not  supported  by  a  Logical  Time  which  is 
PORT  Link  Assigned  to  some  communicant  UU  (unshaded  boxes). 

4. 2. 3. 2  The  A-Level  Logical  Times 

The  function  f^  simply  separates  these  Logical  Times  in  T^.  (which  are 

candidates  for  PORT  Link  Assignment)  into  the  A-level  ones  (T^)  and  all 
the  rest  (T^.  since  the  A-level  candidates  will  be  treated  differently 

(f&)  and  considered  first  (fg)  for  PORT  Link  Assignment. 


This  separation  of  A-level  logical  times  corresponds  to  the  PPS  statement: 
"Whenever  the  MU  is  the  supporting  unit  of  an  available  PLA,  all  unassigned 
A-level  PLAs  shall  be  considered."  This  statement  is  a  bit  problematical, 
for  --  the  "MU  is  the  supporting  unit  of  an  available  PLA,"  then  the 
implication  is  that  the  MU  is  one  of  u.'s  communicants.  Hence  it  follows 
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logically  from  the  search  algorithm  as  stated  for  the  general  case  that 
any  unassigned  A-level  Logical  Time  will  be  automatical ly  among  those 


considered  for  assignment.  Thus,  as  worded  in  the  PPS,  the  requirement 
is  unnecessary;  it  could  be  taken  to  mean,  "...all  unassigned  A-level 
PLAs  shall  be  considered  first."  This  seems  like  a  not  unreasonable 
requirement,  since  the  A-level  Logical  Times  are  also  singled  out  for 
a  special  test,  and  from  the  STD,  the  philosophy  seems  to  be  that  one 


tries  to  fill  in  A-level  "branches"  in  the  trees  first. 


Our  search  algorithm  itself,  f7>  is  arranged  to  take  this  into  account, 

by  first  looking  at  the  A-level  Logical  Times  separately  in  fg.  Then  if 

a  t"  is  found  among  the  A-level  Logical  Times,  it  is  made  the  new 
new 

PLA,  t‘  ,  by  f„.  If  no  t"  is  found  among  the  A-level  Logical  Times, 
new  J  9  new 

fg  directs  f10  to  look  among  all  the  others  (Tc  _A)  for  a  possible  PLA. 

The  second  way  in  which  A-level  Logical  Times  are  treated  differently 
is  in  being  subjected  to  the  test  in  f^,  which  corresponds  to  the 
PPS  statement,  "The  A-level  PLAs  shall  be  assigned  to  different  trees 
until  all  allocated  trees  have  been  used  at  least  once."  That  is, 

UUs  shall  be  assigned  to  Logical  Times  with  different  tree  numbers, 
until  there  is  at  least  one  PLA  for  every  tree.  (Incidently,  note 
again  that  the  sentence,  as  worded,  is  meaningless:  if  PLA  is  intended 
to  mean  "Logical  Time,"  it  is  false,  because  Logical  Times  have  a  fixed 
tree  number  and  cannot  be  "assigned"  to  a  tree--they  are  already  by 
definition  jrn  a  tree.  If  PLA  really  does  mean  PORT  Link  Assignment, 
then  a  PORT  Link  Assignment  can't  be  assigned;  only  UUs  can  be  assigned 
to  Logical  Times  and  vice  versa.  Hence,  it  should  read,  "The  A-level 
UUs  shall  be  assigned..."  or  even  more  accurately,  "If  there  are  any 
trees  all  of  whose  Logical  Times  are  unassigned,  UUs  should  be  assigned 
to  A-level  Logical  Times  in  these  trees  first." 

In  less  formal  terms,  in  the  initial  stages  of  building  the  network, 
one  wants  to  fill  all  the  trees  as  quickly  as  possible,  so  that  there  are 
no  "empty"  trees,  i.e.,  ones  whose  logical  times  are  assigned  to  no  UUs 
at  all.  Thus,  if  there  are  any  "empty"  trees  still  in  the  network,  we 
must  try  to  assign  our  UU^  to  one  of  them  first  (and  since  they  are 
"empty",  it,  of  course,  has  to  be  an  A-level  assignment). 


This  is  illustrated  in  Figure  4. 2. 3. 2-1.  The  cross-hatched  boxes  represent 
Logical  Times  assigned  to  the  MUwhich  potentially  T-support  Logical  Times 
at  the  A-level.  In  the  picture,  two  of  these  (the  black  ones)  have  been 
assigned  to  UUs,  one  in  Tree  1  and  the  other  in  Tree  5.  Trees  12  and  17 

have  no  UUs  assigned  to  their  Logical  Time  slots.  Thus,  if  we  have  a  UU 

requesting  entry,  we  would  want  to  assign  it  to,  say,  Tree  12. 

This  is  what  f  does.  Since  it  is  essentially  an  existence  test  ("Do 
any  empty  trees  exist?"),  like  all  existence  tests,  it  is  somewhat  cum¬ 
bersome.  T-  -t.j  i  is  the  set  of  available  Logical  Times  which  happen  to 

belong  to  empty  trees.  If  there  are  any,  function  g.  sets  T‘.  =  T.  .f.  , ; 

otherwise,  T'ft  =  the  original  T^  that  we  started  with,  and  the  computation 
continues  in  a  normal  fashion. 

4. 2. 3. 3  Restrictions  on  PLAs 

Functions  fg  and  f  are  requirements  imposed  upon  the  choice  of  Logical 
Times  before  we  even  begin  the  search.  Function  f^  insures  that  there 
are  no  loops— that  the  network  of  UUs  and  Logical  Times  is  really  tree¬ 
like."  It  is  assumed  that  it  is  desirable  not  to  have  either  "real" 
loops  (in  the  same  tree;  see  Fig.  4.2.3.3-la)  or  "virtual"  loops  (the 
two  UUs  active  in  different  trees,  Fig. 4. 2. 3.3-1 b) .  While  this  seems 
desirable  from  a  practical  point  of  view  (we  want  a  maximally  spread- 
out  netowrk,  so  that  if  one  UU  is  knocked  out  of  action,  it  will  create 
a  minimal  disturbance  of  communication  links),  it  does  impose  a 
severe  restriction  on  the  number  of  Logical  Times  available  for  PORT 
Lin Assignment  to  a  given  UU.  Also  (like  function  f  ),  it  is  rather 

Ct 

complex  computationally,  as  can  be  seen  from  the  control  map  in  Figure 
4. 2. 3. 3-1.  While  the  Logical  Times  that  don't  meet  the  condition  "not 
...supported  by  a  UU  that  already  cooperates  in  a  PLA  wi  1  the  specified 
UU"  [  ],  this  condition  is  quite  complex  computationally,  as  we  can  see 

by  its  control  map  (Fig.  4.2.3.3-la,  fD).  (Again  an  existence  condition!-- 
"Does  a  'JU  exist  such  that  one  of  its  assigned  Logical  Times  support  the 
proscsed  Logical  Time  being  considered  for  assignment  to  u^  and  whose 
ot;'.-r  assigned  Logical  Time  is  either  T-supported  by  or  T-supports  the 
other  _ogical  Time  of  ui ?") 
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INITIAL  SPREAD  ACROSS  TREES 


IBBBBBI 


with  TN 


Definition  of  COOPERATE: 


OPERATION:  boolean  =  Ucoop?(up 
WHERE  u i  ,u2  ARE  UUs; 
Ucoop?(uru2)  =  0R(Usupp?(u1  ,u  ) 
END  Ucoop?; 


Figure  4. 2.3.3- 
(con’t) 


u2); 


,  Usupp?(u2,u1)) 
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Function  f  does  not  seem  as  complex  only  because  we  have  already  defined 
AISF  (Active-in-Same-Frame)  as  an  operation  in  the  section  on  data  types. 
Furthermore,  the  requirement,  as  stated  in  the  PPS,  is  that  the  Logical 
Time  not  be  considered  if  it  "is  active  in  frames  that  coincide  with  the 
specified  UU's  other  PLA"  (emphasis  added).  Unfortunately,  specifying 
other  is  not  so  easy  as  it  might  seem  at  first  glance,  because  of  the 
duplexing.  To  illustrate,  consider  an  early  problem  that  we  ran  into 
in  understanding  the  PPS:  Figure  4. 2. 3. 3-2  (PPS  Figure  3. 4. 2-2),  we 
were  surprised  to  find  that  although  the  PORT-Link  supporting  UUg  (going 
through  UU^)  is  the  second  PLA  for  UU^  (c.f.  row  d2  in  the  chart,  where 
the  rate  is  entered  in  column  APL^,  not  column  ALP1),  and  yet  the  rate 
for  UUc  was  entered  in  column  APL1_,  indicating  that  this  Logical  Time 
was  the  first  PLA  for  unit  UUC>  That  is,  there  i_s  no  fixed  concept  of 
"other,"  i.e.,  of  first  or  second  PLA,  as  we  have  noted  in  the  data¬ 
type  specifications,  if  we  say  UU1  supports  UU2  and  PLA(u-)  =  t  ,tb, 
PLA(u2)  =  tc,tj.  We  have  no  v/ay  of  knowing  in  advance  of  actually  check¬ 
ing  all  the  possibilities  whether  t  T-supports  t  ,  or  if  t  T-supports 
tc>  or  if  tfa  T-supports  tc,  or  vf  T-supports  trf!  --four  possibilities! 

Hence,  the  address  of  the  "other"  PLA  for  some  given  UU  is  not  a  constant 
(like  "FIRST"  or  "SECOND"),  but  must  be  referenced  either  by  including 
the  other  PLA  (e.g.,  the  other  Logical  Time,  tQther)  as  an  input  to  the 
search  algorithm,  or  by  calculating  it  when  we  need  it  (Figure  4. 2. 3. 3-3). 

4. 2. 3. 4  The  Search  Itself 

Finally,  we  come  to  the  search  algorithm  itself,  which  is  fairly  straight¬ 
forward,  compared  to  the  other  tests  and  conditions.  This  is  done  in 
Function  ffi.  After  seeing  all  the  above  complexity,  it  should  be  noted 
here,  that  when  a  simple  condition  is  imposed  (instead  of  the  very  complex 
conditions  suggested  by  the  PPS  for  the  previous  tests),  the  AXES  struc¬ 
ture  SET-TEST  allows  a  very  simple  and  clear  statement  of  the  requirements 
(Figure  4. 2. 3. 4-1).  On  the  right-hand  side  of  the  Cojoin,  we  simply  take 
the  set  we  began  with  (T-j)  and  throw  out  all  the  Logical  Times  whose 
periods  are  not  equal  to  the  required  period.  If  there  are  none  left, 

T2  =  REJECT,  and  the  FAILURE  structure  (an  AXES  library  structure  of  Ap¬ 
pendix  II)  allows  us  to  try  a  different  function,  in  this  case  looking  for 
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the  Logical  Times  with  periods  less  than  the  required  period.  If  there  are 
none,  FAILURE  again  lets  us  try  a  third  possibil ity— greater-than  the 
required  period.  (Note  that  less  and  greater  have  been  reversed  because 
we  are  checking  period,  rather  than  cycle  rate,  c.f.  comment  in  Footnote 
#2).  We  do  not  need  a  third  FAILURE  since  the  top  level  of  Tie-Break 
will  pass  on  a  REJECT  if  there  are  no  possible  assignments. 

The  Tie-Break  operation  (Figure  4.2.3. 4-2)is  also  fairly  self-explanatory, 
except  that,  as  given  in  the  PPS,  it  does  not  break  all  possible  ties. 

To  see  why  this  is  so,  remember  that  Logical  Times  are  exhaustively  de¬ 
fined  by  PERIOD,  LEVEL,  TREE-NUMBER,  and  START-FRAME.  While  given  a 
particular  start-frame,  level,  and  tree-number,  there  can  be  only  one 
period  (because  of  Axiom  5  of  data-type  Logical  Time),  it  is  perfectly 
possible  for  there  to  be  two  Logical  Times  with  the  same  period,  level, 
and  start-frame  but  different  tree  numbers.  (The  reader  can  demonstrate 
this  by  working  through  the  Logical  Times  t^  -  t£  in  Figure  4. 2. 3. 4-3. 

There  is  no  way  to  choose  between  tft  and  t  .)  We  have  suggested  an  arbi¬ 
trary  fourth  test  based  on  tree-number  as  part  of  the  Tie-Break  opera¬ 
tion. 

4.3  Conclusion 

In  summary,  an  exact  specification  of  this  module  (FIND-PLA)  in  HOS  terms 
would  consist  of  the  control  map  accompanying  AXES  statements  (with  per¬ 
haps  a  minimal  explanatory  corrmentary)  and  the  data-type  specifications, 
which  would  cover  all  the  modules.  This  is  what  a  rewrite  of  the  PPS 
would  consist  of  in  HOS  terms.  A  sample  explanatory  commentary  for  such 
a  rewrite  is  given  in  Figure  4.3-1.  It  is  interesting  to  compare  this 
with  the  original  PPS  page  3-43  that  we  started  out  with.  In  order  to 
turn  this  into  a  detailed  and  explicit  specification  (e.g.,  one  that 
could  be  coded  from  in  some  relatively  straightforward  way),  there  were 
many  problems  to  be  resolved  and  hidden  implications  to  be  discovered. 

For  example,  Figure  4.3-2  shows  some  of  the  words  used  in  a  technical 
sense,  just  in  this  one  section  of  the  PPS  (Sect.  3.4. 2. 2. 3)  along  with 
some  problems  (discussed  earlier)  regarding  their  meaning.  Similarly, 
Figure  ^.3-3  highlights  some  of  the  functional  problems:  (1)  there 
is  no  order  among  the  operations  and  tests  suggested  (functions  are  marked 
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V 


WORDS  NEEDING  DEFINITION: 


PLR  (PORT  Link  Assignment): 

can  mean  either  (1)  the  assignment  process 

e.g.,  "assignment  of  a  PORT  link"  (STD  p.  3.3-12) 


(2)  the  thing  assigned 

e.g.,  "assigned  PLA"  (PPS  3. 4. 2. 2. 2. 3. 2) 
"unassigned  PLA" 

Not  even  defined  in  glossary  to  PPS  (Appendix  B) 


UU  (User  Unit) 

MU  (Master  Unit) 


need  to  be  of  same  data  type 


level  -  the  MU  also  has  a  level 

Support  -  Used  to  mean: 

U-supp?  (uj^) 

T-supp?  (t1 ,t2) 

T-supp?  (ALPtuj)^)  "PLA  is  supported  by  a  UU..." 

Cooperate  -  not  defined  in  glossary 

Tree  -  doesn't  mean  links  and  nodes 
reens  sets  of  time  slots 

"■•ame  -  glossary  definition  doesn't  mention  it 
is  composed  of  time  slots 

Rate  -  they  -ean  period 

Pl:  ‘  -  should  be  PLA  or  "t" 


eve -  needs  to  be  an  operation 

PLA  state  -  simply  means  high  or  low  period 


TECHNICAL  TERMS  NEEDED  FOR  THIS  SECTION 


3.4.2. 2.2. 3  PORT  link  assignment  selection.  PORT  link  assignment  selection 
shall,  unless  requested  otherwise,  determine  the  best  match  between  UU  desired  PL 
states  and  available  PLAs .  Available  PORT  link  assignments  shall  be  determined 
from  the  unassigned  PLAs  directly  supported  by  active  UUs .  When  no  PLA  is  available 
for  assignment  to  a  UU  designated  for  PL  state  change,  that  UU  shall  be  requested 
to  demand  entry.  The  PLA  selection  criterion  and  PLA  restrictions  are  defined  in 
the  following  subparagraphs. 

3. 4. 2. 2. 2. 3.1  PLA  selection  criterion.  The  best  match  between  the  desired  PL 
state  and  the  available  PLAs  shall  be  selected  using  the  following  order: 

a.  PLA  with  an  exact  match  between  the  desired  and  available  rate  (period) 

b.  PLA  where  the  desired  rate  is  lower  than  the  available  rate 

c.  PLA  where  the  available  rate  is  lower  than  the  desired  rate 

For  otherwise  identical  PLAs,  selection  shall  be  made  in  the  following  preference 
order: 

d.  PLA  with  lower  levels 

e.  PLA  with  a  closer  rate  match  to  the  desired  rate 

f.  PLA  with  earlier  start  frames. 


3. 4. 2. 2. 2. 3. 2  PORT  link  restrictions.  Available  PLAs  shall  not  be  considered 
for  assignment  if  the  PLA  either  is  supported  by  a  UU  that  already  cooperates  in  a 
PLA  with  the  specified  UU,  or  is  active  in  frames  that  coincide  with  the  specified 
UU's  other  assigned  PLA.  Whenever  the  MU  is  the  supporting  unit  of  an  available 
PLA,  all  unassigned  A-level  PLAs  shall  be  considered. 

Each  PLA  shall  be  supported  by  only  one  UU.  No  two  UUs  shall  have  the  same 
PLA.  A  PLA  previously  assigned  to  a  UU  shall  not  be  available  for  reassignment  until 
its  deassignnent  or  replacement  has  been  explicitly  acknowledg'd  by: 

a.  A  PLA  command  acknowledge 

b.  A  mode  command  acknowledge 

c .  UU  tine  out. 

The  A-level  PLAs  shall  be  assigned  to  different  trees  until  all  allocated  trees  have 
been  used  at  least  once. 
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3. 4. 2. 2. 2. 3  PORT  link  assignment  selection.  TORT  link  assignment  selection 
shall,  unless  requested  otherwise,  determine  the  best  natch  between  UU  desired  PL 
states  and  available  PLAs.  Available  PORT  link  assignments  shall  be  determined 
from  the  unassigned  PLAs  directly  supported  by  active  tills  .  When  no  PLA  is  available 
for  assignment  to  a  UU  designated  for  PL  state  change ,  that  UU  shall  be  requested 
to  demand  entry.  The  PLA  selection  criterion  and  PLA 
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3.4 . 2 . 2 . 2 . 3. 1  PLA  selection  criterion.  The  best  match  between  the  desired  PL 
state  and  the  available  PLAs  shall  he  selected  using  the  following  order: 

I  a.  PLA  with  an  exact  match  between  the  desired  and  available  rate  (period) 

b.  PLA  where  the  desired  rate  is  lower  than  the  available  rate 

c.  PLA  where  the  available  rate  is  lower  than  the  desired  rate 


For  otherwise  identical  PLAs,  selection  shall  be  made  in  the  following  preference 
order : 

d.  PLA  with  lower  levels 

e.  PLA  with  a  closer  rate  match  to  the  desired  rate 
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3.4 . 2 . 2 . 2 . 3.2  PORT  link  restrictions^  Available  PLAs  shall  not  be  considered 
for  assignment  if  the  PLA  either[is  supported  by^a  UU  that  already  cooperates  in  a 
PLA  with  the  specified  UU,]or[is  active  in  frames  that  coincide  with  the  specified 
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; he  A- level  PLAs  shall  be  assigned  to  different  trees  until  all  allocated  trees  have 
been  used  at  least  once. 
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where  their  verbal  descriptions  appear  in  the  PPS  test;  compare  to  the 
control  map).  (2)  Some  statements  are  either  meaningless  or  false,  e.g., 
"Each  PLA  shall  be  supported  by  only  one  UU."  First  of  all,  UUs  U-support 
other  UUs  and  Logical  Times  T-support  other  Logical  Times,  so  a  UU  can't 
support  a  Logical  Time  (and  certainly  not  a  "PLA").  We  then  might  ask 
if  it  means  “a  Logical  Time  has  only  one  UU  assigned  to  it"  (in  which 
case  it  is  trivally  true,  by  definition),  or  if  it  means  "a  Logical 
Time  is  T-supported  byonlyone  other  UU's  Logical  Time,"  in  which  case 
it  is  false,  since  any  Logical  Time  is  supported  by  several  other  Logical 
Times  and  we  must  assume  they  mean  directly  T-supported.  But  this  is 
inherent  in  the  way  Logical  Times  are  defined  (in  the  data-type  defini¬ 
tions).  So  it  is  not  clear  this  has  anything  to  do  with  the  search  al¬ 
gorithm.  (3)  Some  statements  are  unnecessary.  The  statement  "No  two  UUs 
shall  have  the  same  PLA"  is  redundant,  since  one  can  only  make  PORT  Link 
Assignments  from  unassigned  Logical  Times  in  the  first  place.  (4)  Some 
statements  properly  belong  in  other  sections,  e.g.,  the  statement  which  be¬ 
gins  "A  PLA  previously  assigned..."  and  which  includes  the  three  cate¬ 
gories  (a-c)  has  nothing  to  do  with  PLA  selection,  but,  as  we  can  see 
from  the  control  map,  tells  which  Logical  Times  are  going  to  be  in 
Tunassigned*  3ut  thls  is  determined  the  result  of  applying  the  opera¬ 
tion  ALP(t)  and  the  result  will  depend  on  which  PLAs  are  currently  in 
force.  But  if  the  CLEAN-UP  function  does  actual  assignment,  then  the 
timing  of  when  we  deassign  PLAs  properly  belongs  in  that  module,  not 
as  part  of  the  search  algorithm.  Similarly,  the  statement  "When  no  PLA 
is  available  for  assignment  to  a  UU...  that  UU  shall  be  requested  to  de¬ 
mand  entry"  is  properly  the  response,  or  recovery  from  REJECT  in  FIND-PLA, 
and  a  1  chough  it  could  conceivably  be  generated  by  the  top  level  of  FIND-PLA 
(i.e.,  generate  a  DEHAND-ENTRY-REQUEST),  again  this  seems  properly  the 
function  of  a  module  outside  FIND-PLA,  as  noted  in  Footnote  #4. 

To  reiterate,  this  sample  specification  for  Section  3. 4. 2. 2. 2. 3  [H]> 

Figure  4.3-4,  has,  of  course,  not  sol ved  all  of  the  problems,  some  of 
which  require  more  system-wide  solutions.  But  it  has  pointed  out  and 
suggested  possible  resolutions,  which  might  be  taken  into  consideration 
as  the  specification  of  the  PLRS  Network  Manager  continues. 
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SAMPLE  RE-WRITE  OF  PPS  SECTION  3. 4. 2. 2. 2. 3 


3. 4.2. 2.2 . 3  PORT  LINK  ASSIGNMENT  SELECTION 

This  module  attempts  to  find  a  logical  time  whose  period  is  as  close  as 
possible  to  the  period  generated  by  the  PORT  Link  State  Transition  Processing 
module,  and  passes  this  new  logical  time  to  the  PORT  Link  Assignment  and 
Correction  nodule. 


VARIABLE 


DATA-TYPE 


I N°UTS 


OUTPUTS: 


01  message 
MTC  message 


i  nteger 


User  Uni t 


loci  cal  time 


tuple  (of  logical 
time) 

logical  time 


MEANING 

Recommended  period 

The  UU  being  considered 
for  reassignment 

The  LT  of  the  PLA  being 
considered  for  change 

The  possible  logical  times- 


The  new  LT  found 


data-type  to  be  specified 


This  could  be  list,  file,  array,  depending  upon  implementation  layer 
cons i derat i ons . 


The  module  first  conducts  a  Search  for  a  new  logical  time,  then  detects,  if 
necessary,  a  failure  to  find  one,  and  responds  with  error  message. 

First  the  function  f  (Figures  4.2. 1-3  and  4.2.3'D  computes  (or  calls  from 
memory)  the  logical  tires  wnich  are  unassigned:  ALP(t)  =  REJECT.  This  func¬ 
tion  outputs  the  set  (list,  array,  etc.)  TynaS5;gned. 


The  ne*t  function,  f  finds  which  are  the  logical  times  that  T_support  the 

I  a 

logical  tires  in  T, , _ . _ ,.  (f,  =  T _ _  =  DTsupp[TM^_^  . _ ,])) 


Unassicned'  'l  supporting 


Unass i gnedJ 


(The  orrcsss  in  functions  f  ^  -  f ^  is  illustrated  schematically  in  Figure  4.2. 


Figure  4.3-4 
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We  then  find  which  of  these  logical  times  are  PORT  Link  assigned  to  the 

A 

user  unit  u.'  communicants.  (f„:  T„  IS  FORMED  FROM  T  .  FORALL 

i  2  C.  supporting 

E 1 emen  t  ? (ALP ( t ) , C . ) ) 

We  then  find  which  logical  times  the  communicants'  logical  times  support 
(fj)  and  divide  them  into  A-level  and  non-A-level  logical  times  (f^). 

We  can  now  conduct  the  search  for  the  best  match ,  after  first  eliminating  the 
logical  times  which  fail  to  meet  certain  requirements. 

For  the  A-level  ones,  T^,  we  attempt  to  have  at  least  one  assignment  for 
every  tree  as  soon  as  possible  in  the  beginning  stages  of  building  the 
network;  therefore  we  apply  f  ,  which  checks  to  see  if  there  are  any  "empty" 
trees,  and  if  so,  picks  a  logical  time  from  one  of  them  if  possible 
(Figure  4. 2. 3. 2-1). 

The  rest  of  the  tests,  f^-  f^,  are  run  first  on  the  A-level  logical  times, 
and  if  no  candidate  for  PORT  Link  Assignment  is  found,  the  same  tests,  f  - 

are  run  on  the  rest  of  the  logical  times,  Tc  _A 

i 

Function  f^  checks  the  logical  times  to  make  sure  the  PORT  paths  formed  by 
such  an  assignment  will  be  district;  i.e.,  not  cross  or  form  loops,  either 
real  (in  the  same  tree)  or  virtual  (in  different  trees)  (Figure  4. 2. 3.-1). 

Function  f^  eliminates  from  consideration  those  logical  times  which  are  active 

in  the  same  frames  as  the  User  Unit  u. 's  other  assigned  logical  time  (Figure  4. 2. 3-1). 

The  final  operation,  f^,  then  attempts  to  find  a  logical  time  whose  period 
matches  most  closely  the  given  period  (Figure  4. 2. 3.4-1),  and  if  more  than 
one  is  found,  breaks  the  tie  using  the  criteria  indicated  in  the  operation 
(Tie  Break,  Figure  4.2. 3*4-2  and  Figure  4. 2. 3-4-3)- 

If  at  any  point  the  set  of  logical  times  being  considered  becomes  empty,  a 

REJECT  is  generated  and  passed  along  the  top  levels  of  the  various  functions  and 

is  output  as  the  value  of  t'  If  t1  =  REJECT,  then  t  is  set  equal  to 

new  new  new 

told’  an<^  aPProPr'ate  meassages  to  the  I/O  and  MTC  are  generated  (Fig.  4.2. 1-2). 

Figure  4.3~4  (con't) 
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5.0  REVIEW  OF  SUBSTANTIVE  PROBLEMS  IN  REAL  TIME  PLRS  DESIGN 


In  the  beginning  of  the  PLRS  project,  we  reviewed  the  preliminary  Pro¬ 
gram  Performance  Specification  [  ].  It  has  been  the  case  that  many  of 
the  errors  we  detected  in  this  primary  document  have  been  cleared  up 
in  the  final  PPS.  In  addition,  many  of  the  things  which  we  found  missing, 
ambiguous,  or  wrong  in  the  PPS  have  been  straightened  out  in  the  STD 
and  through  discussion  with  members  of  the  PLRS  project.  It  seems  as 
if  the  closer  the  system  gets  to  implementation,  the  better  the  system 
is  specified.  (An  example  of  this  is  provided  by  the  PORT  Link  Assign¬ 
ment  Command  "in  the  STD,  which  specifies  the  necessary  data  for  a  PLA 
better  than  the  entire  discussion  in  the  PPS.)  While  the  trend  toward 
better  design  as  the  system  moves  closer  to  implementation  is  encouraging, 
it  is  not  the  best  way  to  develop  systems  according  to  HOS  principles. 
And,  despite  the  improvement,  some  substantial  errors  remain.  This  sec¬ 
tion  will  describe  how  these  problems  and  errors  are  detected.  A  re¬ 
presentative  list  of  them  will  be  described  in  some  detail.  Finally, 
we  will  summarize  them  by  category  and  discuss  how  the  consistent  appli¬ 
cation  of  HOS  principles  can  be  used  to  avoid  them. 

5.1  Examples  of  Problem  Categories 

5.1.1  Confusion  between  the  Network  of  Units  and  the  Network  of  Logical 
~  ir.es 


This  confusion  is  displayed  in  several  ambiguities.  For  example,  the  term 
tree  is  used  both  in  the  conventional  graph  sense  (as  a  hierarchical 
set  of  units)  and  in  a  special  sense  of  a  set  of  timeslots.  We  will 
describe  three  problems  arising  out  of  this  confusion. 

PLA  Confusion 

Tnroughout  the  PPS,  there  is  confusion  regarding  PORT  Link  Assignments 
(i.e.,  a  set  of  transaction  groups  -  16  timeslots  -  during  which  another 
set  of  VJs  are  communicating)  and  PLAs,  which  are  often  used  in  the  sense 
of  r.ssiole  or  potential  transaction  groups.  This  confusion  is  reflected, 
for  example,  in  the  concept  of  "unassigned  PLAs"  (see  PPS,  Sect.  3 .4 . 2. 2. 2. 3) . 
Tre  'act  that  PORT  Link  Assignment  is  not  a  glossary  entry  is  not  helpful. 
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The  implication  of  this  confusion  is  that  the  procedures  for  finding 
available  transaction  groups  to  be  used  as  a  PLA  cannot  be  clearly 
specified. 

This  problem  was  identified  by  trying  to  determine  formal  data  types 
to  be  used  in  the  control  map.  (See  discussion  in  Section  3.6  and  3.7.) 

Confusion  between  Units  and  Logical  Times 

Clearly,  information  regarding  both  units  (e.g.,  communicants)  and  Logical 
Times  (e.g.,  which  contain  cycle  rates)  must  be  considered  in  managing 
the  network.  However,  these  two  concepts  must  not  be  confused.  For 
example,  when  (in  PPS  Sect.  3. 4. 2. 2. 2. 3. 2)  it  is  said,  "Each  PLA  shall 
be  supported  by  one  only  UU",  the  concepts  are  mixed.  Elsewhere 
(PPS  Sect.  3. 4. 2. 2. 2.1 .3)  PLA's  support  other  PLAs  and  units  support 
units. 

This  problem  was  discovered  while  formulating  the  data  types. 

Primitive  Operations 

In  the  PPS  (especially  Section  3. 4. 2. 2. 2. 3. 2) ,  the  confusion  between 
links  and  units  leads  to  a  corresponding  confusion  between  the  primitive 
operations  which  might  be  performed  on  each.  In  the  statement,  “Each 
PLA  shall  be  supported  by  one  one  UU",  the  implication  is  that  UUs  sup¬ 
port  PORT  Link  Assignments  (rather  than  UUs  supporting  UUs).  As  stated 
the  sentence  suggests  that  "find  the  unique  UU  supporting  this  PLA" 
would  be  a  legitimate  operation.  In  actuality,  the  appropriate  operation 
is:  "find  a  UU  among  the  set  of  communicants  whose  PLA  may  support 
another  PLA." 

Implications  of  the  confusion  between  primitive  operations  is  that  the 
software  developers  cannot  be  certain  of  quite  what  qualities  are  sig¬ 
nificant,  hence  they  cannot  be  sure  of  how  to  implement  the  constraints. 

This  confusion  was  discovered  during  the  preparation  of  the  operations 
for  use  in  the  control  map. 
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5.1.2  Potential  Sources  of  Loss-of-Control 


As  the  system  is  described  in  the  PPS,  there  is  not  strict  continuity 
in  the  flow  of  control  in  the  Network  Manager's  operations.  For  example 
(PPS  3.4.2.2.1 .1 .3),  Handover-in  UU  processing  is  described  in  terms  of 
what  will  have  happened  after  the  process  is  completed.  Working  from 
the  available  description,  we  can  assume  that  MTC  informs  NM  that  a  UU 
is  to  be  handed-over.  (Network  Control  marks  this  UU  as  "zero  rate" 
and  issues  a  tree  allocation  command.)  MTC  passes  this  command  onto 
the  UU.  Then  the  PPS  says,  "Upon  acknowledgement  of  this  command,  net¬ 
work  control  shall  generate  a  handover-in  successful  notice."  As  written, 
this  description  does  not  include  the  possibility  that  the  UU  fails  to 
respond.  If  this  were  to  happen,  it  is  not  clear  where  the  control 
stopped.  Is  the  next  function  to  be  performed  in  network  control,  in 
message  traffic  control,  in  both,  or  in  neither? 

The  serious  implications  of  this  sort  of  ambiguity  are  obvious!  And  it 
ray  arise,  in  basically  the  same  form,  for  a  wide  variety  of  commands 
which  expect  a  response  from  the  UU  community. 

These  problems  were  discovered  by  trying  to  build  the  control  map  of  the 
network  manager. 

5.1.3  Inconsistent  I/O  Interfaces 

In  the  original  PPS,  this  sort  of  problem  was  very  prevalent.  The  re¬ 
vised  PPS  has  cleared  up  some  of  these  problems,  but  most  remain. 

Na~e  Changes 

Several  data  elements  have  different  names  and  different  membership 
at  different  levels  of  documentation  detail.  For  example,  in  Figure 
3. 3. 5-1  [11],  the  01  inputs  UU  CONTROL  to  the  NM;  in  Figure  3.4. 2-1 
[11],  if  inputs  UU  MODE  CONTROL;  in  Section  3. 4. 2. 1.2. 4  [11],  "the  new 
NM  *v  ction  shall  accept  inputs  from  the  01  function  consisting  of:... 

1.  Ilea r,  2.  Passive,  3.,  Reenter,  4.  Restart".  While  this  may  seem  like 
a  tr  1  problem,  it  must  be  resolved  before  the  system  can  be  expected 
to  ccc-rate.  Why  not  avoid  the  problem  by  a  disciplined  consistency 
fro~  the  very  beginning? 
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Other  examples  of  this  kind  of  problem  include  missing  UU  OCCUPANCY, 

UU  STATE,  CURRENT  CLA,  CURRENT  PLA,  FORCE  PLA  ALERT,  ZERO  ALERT  (or 
ZERO  LINK  ALERT),  etc.,  in  Figure  3. 3. 5-1  [11];  unique  NETWORK  VALUE, 
and  others. 

These  inconsistencies  were  discovered  while  formulating  the  preliminary 
control  map. 

Identity  of  Data  Items 

This  problem  involves  the  completeness  and  the  consistency  of  the  PPS 
as  a  document  from  which  to  develop  software.  Therefore,  it  should  be 
self-contained.  But  it  is  not  clear  within  the  PPS  what  UU  MODE  (for 
example)  signifies.  Similarly,  the  meaning  of  R  and  S-type  PORT  Link 
rates  is  unclear.  The  fact  that  the  identity  of  data  items  seems  to 
change  according  to  documentation  level  was  discussed  above. 

The  implications  of  all  these  inconsistencies  and  ambiguities  is  that 
unnecessary  confusion  is  created  in  the  minds  of  the  software  developers; 
this  confusion  increases  the  likelihood  of  coding  error. 

These  problems  were  discovered  by  trying  to  formally  specify  the  necessary 
data  types  for  the  HOS  control  map,  in  which  specificity  and  consistency 
are  required. 

5.1.4  Functions  Not  Well  Defined 

In  several  places  in  the  PPS,  various  functions  are  invoked  (or  opera¬ 
tions  i-olied)  which  are  not  consistent  with  prior  definition  of  data 
items  or  other  functions.  In  the  software  development  process  currently 
being  used  for  the  PLRS  project,  these  problems  do  not  arise  until  the 
implementation  stage.  But  in  the  software  engineering  process  implied 
by  the  .OS  methodology,  they  are  encountered  early,  and,  therefore, 
can  be  resolved  before  extreme  committment  of  time  and  money  are  made. 
Further-ore,  with  precise  preliminary  specifications,  some  problems 
ao  not  arise  at  all. 
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PLA  Two- Valued  on  Unit 

This  is  simply  the  problem  that  each  unit  has  two  PLAs.  In  the  implied 
search  procedures  to  discover  which  PLA  allows  a  UU  to  receive  commands 
from  the  M’J,  two  outputs  are  possible.  Everywhere  in  the  PPS,  whenever 
a  call  for  a  PLA  associated  with  a  given  unit  is  initiated,  it  is  assumed 
that  one  is  found.  Nowhere  in  the  PPS  is  it  suggested  which  one. 

T^e  implications  of  this  ill-defined  function  (any  function  with  two 
possible  outputs  for  a  given  input  is  necessarily  ill-defined)  are  that 
the  choice  will  be  made  and  it  properly  is  a  choice  to  be  made  by  an 
integrative  systems  designer  with  ample  perspective  on  its  effects;  not 
one  to  be  made  by  a  staff  programmer  for  possibly  idiosyncratic  reasons. 

This  implied  two-valued  function  was  discovered  when  we  tried  to  make  the 
control  functional. 

Cooperate  Ill-Defined 

The  critical  concept  of  "cooperate"  is  used  in  three  different  senses. 

In  PPS  3. 4. 2. 2. 2. 3. 2,  the  phrase,  "the  PLA  either  is  supported  by  a  UU 
that  already  cooperates  in  a  PLA  with  the  specified  UU,"  implies  that 
the  cooperating  UU  is  on  the  same  PORT  Path  (and  at  a  lower  level)  than 
the  specified  UU.  Elsewhere  (in  the  case  of  CLAs),  cooperating  UUs 
are  those  who  "listen"  for  a  specified  UU.  But  in  the  glossary,  a 
coooerating  unit  is  defined  as  "A  PLRS  net  member  whose  transmissions 
are  received  by  another  unit."  This  definition  makes  all  communicants 
'cooperating  units"! 

implication  of  using  one  term  to  signify  many  concepts  is  that  dif¬ 
ferent  people  might  make  conflicting  judgements  about  its  meaning. 

If  the  resulting  implementation  employed  a  test  called  C00PERATE(UU . ,UU • ) , 

*  0 

it  would  be  expected  to  yield  different  values  in  different  modules. 

This  problem  was  discovered  when  the  above  test  was  considered  for  the 
ccrt-'ol  map. 

Perjtj  -  hence  Zero  Rate  =  Period  -»  « 

Ze-’t  rate  has  an  intuitively  plausible  meaning--namely  the  UU  never 
automatically  relays  or  listens  for  transmissions.  However,  a  problem 
a-'ses  in  the  representation  c*  zero  rate  UUs,  because  the  parallel 


concept  of  period  is  also  often  used  to  characterize  them.  Clearly, 

Period^-^-  for  all  rates  allowed  between  1  and  256.  But  when  the  opera¬ 
tions  implied  by  the  PPS  are  attempted  on  zero  rate  UUs,  period  is  trans¬ 
formed  to  "infinity."  This  problem  can  be  handled  at  the  implementation 
stage  by  a  minor  check  for  divide-by-zero  or  the  provision  of  some 
special  code  for  "infinity,"  but  it  is  one  more  thing  that  could  go  wrong 
if  not  noticed  and  treated. 

The  implication  of  this  minor  problem  is  the  possibility  that  the  implied 
arithmetic  might  actually  be  attempted.  Presumably,  this  would  result 
in  a  floating-point  check  and  system  halt. 

This  problem  was  detected  when  we  tried  to  specify  data  types  for  cycle 
rate  and  period. 

5-1-5  Incomplete  or  Wrong  Algorithms 

Although  the  PPS  is  not  consistently  at  the  level  of  detail  of  operational 
algorithms  in  those  cases  where  the  criteria  for  some  system  action  is  im¬ 
portant  (e.g.  chose  a  potential  PLA,  declare  a  link  unreliable  and  a  candidate 
for  replacement,  etc.),  the  PPS  should  specify  either  all  the  criteria 
(complete  the  algorithm)  or  state  that  the  algorithm  is  incomplete. 

There  are  several  cases  in  which  the  PPS  seems  to  specify  how  a  system 
decision  is  to  be  made,  but  omits  crucial  detail. 

Tie-Breaking  Not  Complete 

Section  3. 4. 2. 2. 2. 3.1  specifies  several  criteria  for  the  selection  of  a 
PLA  co  a  unit  when  one  of  its  two  desired  PLAs  is  missing.  But  the 
criteria  as  stated  are  not  sufficient  to  determina  a  unique  PLA.  That 
is,  after  applying  all  the  constraints,  several  possible  PLAs  would 
often  remain.  How  is  the  PLA  Control  function  to  select  from  these 
candidates? 

The  effect  of  this  oversight  is  to  postpone  the  decision  to  implementa¬ 
tion  time.  Eventually,  the  choice  must  be  made.  It  ought  to  be  made 
explicitly  and  on  a  rational  basis  and  not  left  to  programmer  whim. 

This  omission  was  discovered  when  the  function,  "Find  PLA,"  was  specified 
in  control  map  terms. 
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In  Sections  3. 4. 2. 2. 2. 3.1  and  .2,  the  PPS  specifies  the  PLA  selection 
criteria.  Because  reliability  is  a  PLRS  system  goal,  one  restriction 
on  the  two  PLAs  that  serve  a  given  UU  is  that  they  are  relayed  through 
no  conuion  UUs.  This  is  stated  as:  A  PLA  shall  not  be  considered  if 
it  “is  active  in  frames  that  coincide  with  the  specified  UUs  other 
assigned  PLA."  The  selection  criteria  of  Section  3. 4. 2. 2. 2. 3. 1  are  not 
sufficient  to  ensure  this. 

The  implication  of  this  is  that  the  module  which  performs  the  "FIND-PLA" 
function  will  not  have  all  the  information  it  needs,  unless  this  problem 
is  cleared  up  in  implementation. 

This  deficienty  was  discovered  while  formulating  the  "FIND-PLA"  func¬ 
tion  in  the  control  map.  See  discussion  in  Section  3.4.3.  . 

Can't  Find  What  Transaction  Groups  Are  Available  with  Respect  to  Time 
Again,  in  the  FIND-PLA  function,  it  is  necessary  to  determine  which 
transaction  group  ("unassigned  PLA's"  in  PPS  terms)  are  candidates  for 
forming  a  PORT  Path  to  a  given  UU.  One  criterion  is  based  on  UU  data, 
namely  the  set  of  communicants.  The  other  criteria  include  those  in 
Sections  3. 4. 2. 2. 2. 3. 1-2  013-  But  nowhere  in  the  PPS  is  it  specified 

how  the  available  transaction  groups  can  be  discovered.  We  have  solved 
this  problem  by  using  the  control  map  and  primitive  operations  on  the 
HOS  data  types,  but  feel  that  the  PPS  should  have  made  it  explicit  that 
this  algorithm  was  incomplete. 

The  implications  are  that  there  are  several  alternative  ways  to  go  about 
this  necessary  function.  Without  noting  that  the  choice  of  method  is 
being  left  to  a  later  stage,  a  poor  alternative  may  be  implemented  without 
opportunity  for  review. 

This  omission  was  discovered  by  developing  explicit  procedures  for  "FIND- 
PLA"  in  the  control  map.  See  Section  4. 2. 3. 4  fora  more  detailed  explanation. 


What  is  “PORT  Link  Time  Assignment"? 

In  the  Tree  Allocation  Command,  provision  is  made  for  two  3-bit  fields 
which  are  called  PORT  Link  Time  Assignments.  We  found  it  useful  to  refer 
to  the  actual  commands  because  they  are  so  much  more  explicit  (in  most 
cases)  than  the  discussion  in  the  PPS.  We  cannot  find  a  specification  of 
this  data  element  anywhere,  however. 

The  implication  of  this  omission  is  simply  to  leave  uncertainty  in  the 
specification  of  quite  what  this  command  is  meant  to  do. 

This  omission  was  discovered  by  inspection  of  the  STD  in  the  process 
of  formatting  data  types. 

Error  Detection  and  Recovery 

Many  places  in  the  PPS,  an  operation  is  initiated  which  may  or  may  not 
be  successful  (produce  the  desired  effect).  The  most  typical  case  is 
the  generation  of  a  corrmand  to  a  UU  to  take  a  Logical  Time  assignment 
or  to  change  mode.  The  UU  may  or  may  not  respond.  Usually,  the  speci¬ 
fied  action  is  to  generate  a  "zero  alert."  This  in  itself  is  not  suf¬ 
ficient  recovery  procedure.  Because  the  action  to  be  taken  subsequent 
to  the  generation  of  the  alert  is  unspecified,  there  is  no  guarantee 
that  the  system  will  ever  get  back  on  track. 

Error  detection  and  recovery  is  sufficiently  important  that  it  ought 
to  be  explicitly  incorporated  early  in  the  program  development  process. 

A  single  missing  recovery  procedure  could  have  disasterous  consequences 
in  the  field. 

These  considerations  are  an  explicit  part  of  the  HOS  philosophy  and  follow 
directly  from  the  principles  regarding  completeness  of  control. 

5.1.6  Overall  System  Considerations 

This  section  discusses  some  topics  which  we  feel  are  important  considera¬ 
tions  in  the  Network  Manager  function  and  (probably)  for  the  system  as 
a  whole.  They  are  not  problems  in  the  sense  of  the  above,  but  perhaps 
they  should  have  been  treated  in  the  PPS. 


Redvvdant  Operations 

It  seems  as  if  some  of  the  functions  and  operations  necessary  to  imple- 
rentthe  Network  Manager  specification  can  be  used  unchanged  in  several 
places.  For  example,  specification  for  PLA  is  identical  to  CLA.  Both 
are  assignments  of  Logical  Times  to  UUs,  but  the  algorithms  for  finding 
them  may  be  different.  Also,  zero  alerts  are  generated  in  several  places. 
The  opportunity  to  exploit  identical  code  for  redundant  operations  can  be 
seized  only  if  it  is  recognized  early.  In  the  formulation  specified 
in  our  control  map,  for  example,  PLAs  and  CLAs  have  exactly  the  same 
reoresentaticn  (although  they  are  different  data  structures  because 
they  nave  different  meanings).  Similarly,  some  of  the  operations  on 
them  are  identical  in  form.  The  control  map  building  exercise  is  an 
excellent  way  of  discovering  such  operations. 


The  Coerator  and  the  Users  as  Part  of  the  System 

The  PPS  fails  to  consider  the  ML)  operator  and  the  community  users  as 
part  of  the  system.  This  is  an  inadequacy  because  many  of  the  control 
loops  in  the  Network  Manager  (and  other  portions  of  the  PLRS)  are  closed 
only  through  the  operator  or  through  the  community.  That  is,  the  soft¬ 
ware  will  generate  a  condition  (an  operator  message  or  a  command  to  a 
UUO  and  issue  it.  The  next  time  control  passes  back  to  the  software, 
it  is  because  the  operator  or  a  user  has  take  some  action.  At  a  minimum, 
the  range  of  operator  actions  should  be  related  back  to  the  software 
functions  which  (in  some  sense)  initiated  them. 


Treating  the  PLRS  as  a  closed  system  when  it  actually  is  open  to  both 
the  cperator  and  the  users  invites  loss-of-control  problems. 


Tf's  situation  became  evident  when  we  formulated  the  control  map  and 
fc-nc  that  many  of  the  Network  Manager's  control  loops  were  closed 
only  through  the  operator. 
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5.2  Statistical  Summary  of  Problems 


CATEGORIES  OF  PROBLEMS  FOUND 


CONFUSION  BETWEEN  LOGICAL  TIMES  AND  UNITS 
PLA  Confusion 

Units/Logical  Times  Confusion 
Primitive  Operations 


POTENTIAL  SOURCES  FOR  LOSS  OF  CONTROL 
Command/Acknowl edge 


INCONSISTENT  I/O  INTERFACES 

Name  Changes  (Mode  Control ) 
Identity  of  Data  Items 


FUNCTIONS  NOT  WELL  DEFINED 

PLA  Two-Valued 
Cooperate  Ill -Defined 
256 

Period=-^-,  hence  Zero  rate  -*  °° 

INCOMPLETE  OR  WRONG  ALGORITHMS 

Tie-Breaking  not  Complete 
Inflexibility  of  PLA  Rate  Mix 
Can't  find  what  transaction  groups 
available  with  respect  to  time 
What  is  "PORT  Link  Time  Assignment 
in  Tree  Allocation  Command? 

Error  Detection  and  Recovery 
(various) 


OVERALL  SYSTEM  CONSIDERATIONS 

Redundant  Operations  (e.g.,  PLA+CLA) 
Operator  as  Part  of  System 


Impl ication^ 

2 

Frequency 

3 

Discovery 

Serious 

Serious 

Serious 

Often  Formal  Data  Type 

Often  Control  Map 

Often  Control  Map 

Crucial 

Often 

Control  Map 

Minor 

Minor 

Often 

Sometimes 

Control  Mao 
Data  Types 

Crucial 

Serious 

Once 

Once 

Control  Map 
Control  Map 

Minor 

Sometimes 

Data  Types 

Crucial 

Serious 

Once 

Once 

Control  Map 
Control  Map 

Serious 

Once 

Control  Map 

Serious 

Once 

Data  Types 

Crucial 

Often 

Control  Map 

Serious 

Serious 

Often 

Sometimes 

Control  Map 
Control  Map 

Imp! ication  means  expected  magnitude  of  consequences.  It  is  composed  of  the 
probability  that  the  problem  would  go  undetected  times  the  performance  sacrifice 
if  it  occurred. 

2 

Frequency  means  that  it  can  occur  from  2-10  times — often  11-50  instances. 

3 

Discovery  refers  to  the  exercise  that  was  being  worked  on  when  the  problem 
was  recognized. 
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5.3  Considerations  for  Software  Verification 


We  are  given  a  hint  only  of  the  procedures  that  Hughes  employs  to  ensure 
that  the  software  will  work  as  designed.  The  major  weakness  of  these 
procedures  (sketched  in  the  Hughes  Design  Plan),  from  the  perspective  of 
HOS  techniques,  is  that  they  are  informal .  That  is,  they  depend  on  the 
subjective  judgement  of  the  software  creators  as  to  possible  failure 
modes . 

Now,  this  practice  often  may  be  adequate  in  the  sense  that  the  designer 
may  usually  have  a  good  appreciation  of  the  environmental  circumstances 
which  will  impact  his  code.  But,  occasionally,  something  totally  un¬ 
expected  might  happen.  As  a  purely  speculative  example,  consider  a 
spurious  acknowledgement.  Depending  on  the  details  of  implementation 
(within  the  constraints  of  the  PPS),  a  spurious  acknowledgement  could 
hang  up  the  software— searching  for  the  (never-issued)  command  that  it 
thought  was  being  acknowledged! 

One  result  of  this  approach  which  may  prove  troublesome  is  the  dependence 
of  the  designers  of  the  Online  Simulation  Program  on  the  designers  of  the 
Real  Time  PLRS.  Because  the  simulation  program  is  intended  to  demonstrate 
the  MU's  operational  ability  to  meet  specified  requirements,  it  is  im¬ 
portant  that  it  exercise  all  possible  conditions.  From  the  available 
documentation,  it  seems  like  one  of  the  functions  of  the  Real  Time  PLRS 
module  designers  is  to  suggest  modes  in  which  their  modules  ought  to 
be  exercised.  Because  the  conditions  they  anticipate  will  be  the  ones 
they  design  for,  the  power  of  the  simulation  to  detect  error  is  reduced. 

There  is  a  better  way  to  ensure  software  validity!  Because  a  control 
map  constructed  along  the  formal  axioms  of  HOS  must  incorporate  all 
possible  cases  (values,  inputs,  etc.),  it  can  be  used  to  generate  an 
exhaustive  set  of  test  conditions  for  each  functional  module.  Invalid 
data  cannot  hang  the  program--in  the  worst  case,  they  can  only  propagate 
REJECTS  to  the  highest  level,  exactly  the  desired  outcome. 

Software  engineering  directed  by  formal  rules  is  far  more  secure  than 
that  which  depends  merely  on  multiple  levels  of  review. 
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FOOTNOTES 


Footnote  1 

An  object  or  name  can  be  assigned  or  unassigned,  but  an  assignment  can 
hardly  be  assigned  or  unassigned.  Here  it  is  time  intervals  which  are 
either  assigned  to  UUs  or  not  assigned  to  ULIs,  and  the  match  of  a  parti¬ 
cular  UU,  i.e.,  u.  with  a  particular  set  of  time  intervals  in  which  it  is 

active,  i.e.,  t.,  is  what  constitutes  the  PORT  Link  Assignment:  (u.,t.)-- 
J  i  J 

not  the  t.  alone. 

Footnote  2 

It  should  be  noted  that  there  seems  to  be  an  inconsistency  here  in  the 
PPS  text.  Although  the  PORT  Link  Assignment  command  format  indicates 
that  the  Logical  Times  assigned  to  UUs  are  being  specified  using  the  ex¬ 
ponent  on  the  Period,  throughout  the  statement  of  various  algorithms 
in  the  text  this  is  referred  to  as  Cycle  Rate,  rather  than  period.  We 
understand  Cycle  Rate  to  be  equal  to  256/Period,  so  that  it  would  be  a 
simple  matter  in  various  modules  to  convert  from  one  to  the  other,  ex¬ 
cept  for  the  fact  that  Cycle  Rate  is  often  set  to  zero  as  a  means  of 
indicating  a  necessary  change  in  PLA  (c.f.  PPS  Section  3.4.2.2.1 .1 .2, 
p.  3-33,  "Reentry  UUs  shall  be  designated  as  being  in  a  zero  rate  PORT 
link  state  and  shall  be  process  by  PLA  control."),  and  since  P  =  256/CR, 
if  CR  =  0,  P  =  “,not  one  of  the  periods  allowed  for.  There  will  have 
to  be  some  sort  of  ad-hoc  patch;  we  simply  note  the  inconsistency  here. 


Footnote  3 

Given,  for  example,  in  the  STD,  Section  3.5.5,  p.  3.5-10/12,  "Advantages 
of  Network  Redundancy." 


Footnote  4 

Note  Axiom  6b  is  further  complicated  by  taking  into  account  the  Master  Unit, 
wr.ich  ..'9  must  do  for  consistency,  since  the  MU  does  support  the  other  UUs. 
Fcr  example,  if  we  ask  what  unit  directly  supports  some  unit,  the  answer 
(if  it  is  A-level)  may  be  the  MU.  Furthermore,  may  we  not  take  the  al¬ 
ternative  of  using  Axiom  X  ,  Usupp?(m,u)  =  True,  if  there  are  multiple 
■“■Lis,  also  if  we  consider  new  entry  UUs,  which  may  be  communicants  without 
being  supported?  This  requires  further  study,  beyond  the  scope  of  this 
report.  The  final  formulation  of  the  axioms  would  presumably  make  a 
choice  between  Axiom  X  and  Axiom  6b. 


Footnote  5 

We  pit  tore  a  15-frame  epoch  rather  than  a  real  256-frame  epoch  for  sim- 
pl  ic;  *  . 
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M0mjo  buwunot  nufis 


Footnote  6 


CROSS  Link  Assignments  are  omitted  from  this  discussion,  although  they 
would  be  handled  in  an  analogous  manner.  In  addition,  for  the  sake  of 
simplicity,  the  behavior  (specification)  of  the  Master  Unit  is  omitted 
from  the  following  discussion. 


Footnote  7 

Additional  operations  and  axioms  for  data  type  Logical  Time  suggested 
by  Stephen  Kenton. 


Footnote  8 

Including  the  error  recovery  as  part  of  FIND-PLA  was  done  primarily  for 
pedagogical  purposes:  to  show  how  an  error  message  might  be  incorporated 
into  the  specification.  In  a  complete  specification  for  the  PLA  Control 
submodule,  however,  the  error  detection  and  recovery  would  be  done  at  a 
higher  level.  That  is  FIND-PLA  would  consist  basically  of  what  is  called 
SEARCH  in  Figure  4.2.1-3a.  This  might  generate  a  REJECT  as  the  value  of 
t'  which  would  be  passed  up  to  the  operator  system. 

Footnote  9 

That  is,  if  (Tqh)’^)  =  PLA(u^),  where  tQ  is  u^s  other  assigned  Logical 

Time,  or  stated  inversely,  if  u.  =  ALP(tQLp),  then  the  duple  (u1->tQL0) 

must  be  stored  in  memory  somewhere;  this  would  be  replaced  by  the  duple 
( u i , tNEW ) -  That  is,  the  CLEAN-UP  function  would  do  the  actual  changing 

of  PORT  Link  Assignments;  PLA-j  -*•  PLA2  or  rather  (u^.t^)  ■+  (u^,t2). 


Footnote  10 

It  may  be  instructive  to  the  reader  to  work  through  the  recursion  in  SET- 
TEST.  If  so,  note  that  the  final  REJECT  obtained  is  not  an  error;  it 
simply  marks  the  end  of  the  ordered  set  (list,  etc.).  For  example,  if 
we  are  examining  the  items  in  the  list  Tg  =  (7, 3, 8, 2)  and  only  3  and  2 

happer  ::  r.eet  the  required  criterion  being  tested,  then  the  following 
action  occurs: 


7-  IS  FORMED  FROM  T  FORALL  t  <  5; 

.  o 

IN'UT:  T]  =  (7, 3, 8,2) 

REPLACE 

(7. 3. 8. 2)  =  7  and  (3,8,2);  7  is  eliminated. 

(3.3.2)  =  3  and  (8,2);  3  is  saved. 

(3.2)  =  8  and  (2);  8  is  eliminated. 

(2)  =  2  and  REJECT;  2  is  saved. 

2  and  REJECT  =  (2) 

3  and  (2)  *  (3,2) 


OUTPUT:  T-j  =  (3,2) 
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Thus  as  one  can  see,  the  REJECT  is  simply  an  end-marker,  much  like  the 
element  NIL  in  the  LISP  language. 


Footnote  11 

The  operation  Element? (x,S)  is  used  here  in  the  general  sense.  The  AXES 
specification  language  has  the  operation  defined  so  far  only  for  the  case 
in  which  S  is  a  set;  however,  it  is  clear  this  could  be  extended  to  the 
cases  where  S  is  of  some  other  set-like  data  type  (e.g.,  lists,  arrays, 
files,  tuples,  etc.). 
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Preliminaries  of  HOS 


Appendix  II 


Preliminaries  of  AXES 


APPENDIX  1* 

Preliminaries  of  HOS 

In  HOS.  the  decomposition  process  for  a  system  results  m  a  tree 
structure  At  the  start  of  the  decomposition  process,  the  entire 
system  is  represented  by  the  root  of  the  tree  which,  hopefully, 
represents  the  requirements  for  the  system.  This  definition, 
however,  has  many  implicit  (hidden)  requirements.  In  order  to 
arrive  explicitly  at  the  complete  definition  of  the  system,  the  root  is 
decomposed  by  replacing  it  with  a  model  family  (a  particular 
parent  node  and  all  of  its  offspring!,  which  represents  the 
decomposition  of  the  root.  This  decomposition  process,  that  of 
replacing  a  function  by  its  nodal  family,  can  be  continued  until  the 
entire  system  has  been  specified.  The  resulting  tree  represents  the 
complete  system  specification,  where  the  leaves  represent  primi¬ 
tive  operations  on  the  data  types  represented  by  the  variables  at 
those  leaves  It  may  turn  out  that  during  the  decomposition 
process  a  requ.rement  is  shown  to  be  erroneous  or  missing.  In  such 
a  case,  an  iteration  of  the  system  description  is  required. 

The  parent  node  of  the  nodal  family  controls  its  offspring 
When  referring  to  thiscontrol  relationship,  the  parent  node  will  be 
called  a  module,  and  its  offspring  will  be  called  functions]  The 
offspring  of  the  nodal  family  are  the  functions  required  to  perform 
the  module's  lorrespondine  function  (MCF)  (i.e..  the  function 
that  the  nodal  family  replaces). 

In  the  sections  that  follow,  the  variable  that  represents  the 
doma>n  elements  of  a  function  is  referred  to  as  the  input  variable. 
and  the  vartabie  that  represents  the  range  elements  ofa  function  is 
referred  to  as  '.he  output  variable.  Individual  domain  and  range 
elements  may  be  called  inputs  and  outputs  respectively. 

A  module. in  performing itseorrespondingfunctionIFigurc  Al- 
1 1.  is  responsible  for  determining  if  the  inputs  received  are  in  the 
intended  domain  of  the  MCF.  If  an  input  is  not  in  the  intended 
domain  of  the  MCF.  it  is  in  the  unintended  domain  of  the  MCF 
and  maps  to  a  special  value  which  is  a  value  of  every  data  type,  the 
value  Reject. 

In  a  sense,  the  improper  input  element  is  not  in  the  domain  of 
the  module's  corresponding  intended  function  (M IF),  but  is  in  the 
domain  of  the  MCF.  i.e..  the  module's  corresponding  unintended 
function  (Ml'Fl. 

Properties  of  the  Primitive  Control  Structures 

While  a  function  can  be  decomposed  in  mans  ways,  the  HOS 


Figure  Ml.  1 1!  usl  r*  i  ion  of  •  Function  from  X  into  > 


axioms  |  2  )  provide  rules  for  the  construction  of  nodal  lamil.es 
(i.e.,  the  decomposition  of  a  function).  From  these  axioms,  three 
primitive  control  structures,  which  are  used  for  functional  decom¬ 
position.  are  derived  [  1  J 

These  control  structures  are:  composition,  set  partition,  and 
class  partition 


'•  HU  '  MU  S  |  .1 X  ,  >  ,,, 

X  X  l>  »  \ 

Figure  AI-2.  Figure  AI-3. 

An  Example  of  Composition  An  Example  of  Set  Partition 

Composition  is  illustrated  in  Figure  A 1-2  In  order  to  perform 
fi(x).  the  function  f.-  must  first  be  applied  to  x  which  results  in 
output  z.  z  then  becomes  an  input  to  fi  which  produces  the  desired 
range  element  of  the  overall  function. 

It  is  important  to  observe  the  following  characteristics  of 
composition  (characteristics  are  explained  with  respect  to  the 
example  in  Figure  AI-2): 

( 1 )  One  and  only  one  offspring  (specifically  f;  in  this  example) 
receives  access  rights  to  the  input  data.  x.  from  module  I  . 

(2)  One  and  only  one  offspring  (specifically  fi  in  this  example! 
has  access  rights  to  deliver  the  output  data.  y.  for  module  f 

(3)  All  other  inputand  output  data  that  w  ill  be  produced  by  ofi- 
sprtng  controlled  by  f,  will  r»  >de  in  local  variables  l  specifi¬ 
cally  V  in  this  example),  ‘.ocal  variable,  “z".  provides 
communication  between  the  offspring  f:  and  fj. 

(4)  Every  offspring  is  specified  to  be  involved  once  and  onlv 
once  in  each  process  of  performing  its  parent's  MCF. 

(5)  Every  local  variable  must  exist  both  as  an  input  variable  for 
for  one  and  only  one  function  and  as  an  output  variable  for 
one  and  only  one  different  function  on  the  same  level. 

Set  partition,  which  involves  partitioning  of  the  domain,  is 
illustrated  in  Figure  AI-3.  In  the  example,  the  set  w  hich  comprises 
the  domain  is  partitioned**  into  two  subsets.  For  set  partition, 
only  one  of  the  offspring  will  be  invoked  for  each  performance  of 
the  MCF  at  f,  (the  determination  being  based  on  the  value  of  “x" 
received)  and  that  offspring  will  produce  the  required  range 
element  for  its  parent  module  when  it  is  performing. 

The  follow  ing  characteristics  w  ith  respect  to  set  partition  should 
be  observed: 

( 1 1  Every  offspring  of  the  module  at  f,  is  granted  permission  to 
produce  output  values  of  “\“. 

(2)  All  offspring  of  the  module  at  (  ;  re  granted  permission  to 
receive  input  values  from  the  variable  "x". 

••Partitioning  implies  the  subdivision  of  ihc  original  vet  into  nor.- 
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(3)  Only  one  offspring  is  specified  to  be  invoked  per  input  value 
received  for  each  process  of  performing  its  parent's  MCF. 

(4)  The  values  represented  by  the  input  variables  of  an  off¬ 
spring's  function  comprise  a  proper  subset  of  the  domain  of 
the  function  of  the  parent  module. 

(5)  There  is  no  communication  between  offspring. 

Class  partition  is  illustrated  in  Figure  AI-4.  While  set  partition 
involves  partition  of  the  domain  into  subsets,  class  partition 
involves  partition  of  the  domain  variables  into  classes  and  the 
partition  of  the  range  variables  into  classes.  In  the  example,  it  is 
assumed  that  the  domain  variable  has  an  associated  data  structure 
comprised  of  two  parts.“xr  and  “x:“.  Likewise,  the  range  variable 
has  an  associated  data  structure  with  the  same  number  of  classes  as 
the  domain’s  data  structure. 

I\  ,  *  i  -  II*  .  % » 
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Figure  AM.  An  Example  of  Class  Partition 

The  following  characteristics  with  respect  to  class  partition 
should  be  observed: 

( 1 )  All  offspring  of  the  module  at  f  are  granted  permission  to  re¬ 
ceive  input  values  taken  from  a  partitioned  variable  in  the 
set  of  the  parent  MCF  domain  variables,  such  that  each  off¬ 
spring's  set  of  input  variables  is  non-overlapping  and  all 
the  offspring’s  input  variables  collectively  represent  only 
its  parent's  MCF  input  variables. 

(2)  All  offspring  of  the  module  at  f  are  granted  permission  to 
produce  output  values  for  a  partitioned  variable  in  the  set 
of  the  parent  MCF  range  variables,  such  that  each  off¬ 
spring's  set  of  output  variables  is  non-overlapping  and  all 
the  offspring's  set  of  output  variables  collectively  repre¬ 
sent  the  parent  MCF  variables. 

(3)  Each  offspring  is  specified  to  be  invoked  per  input  value  re¬ 
ceived  for  each  process  of  performing  its  parent's  MCF. 

(4)  There  is  no  communication  between  offspring. 

APPENDIX  II* 

Preliminaries  of  AXES 
I.  Axes  Syntax  Description 

AXES  is  a  formal  notation  for  writing  definitions  of  systems. 
These  systems  include  sy  stems  which  are  mechanisms  for  defining 
other  systems.  Thu-  to:  example,  we  could  define  a  set  of 
specification  “macros"  which  collectively  could  form  a  language 
for  defining  a  system  or  iamily  of  systems.  Since  each  language 
statement  would  be  a  definition  “macro"  based  on  an  integrated 
Higher  Order  Software  i  HOS)control  hierarchy[2  ].  the  resource 
allocation  to  a  part.cular  machine  could  then  be  addressed 
independently  from  the  definition  of  the  system.  Although  it  is  not 
a  programming  language.  AXES  is  a  complete  and  well-defined 
language  capable  of  being  analyzed  by  a  computer.  AXES  is 
intended  to  provide  commonality  between  systems.  Although 
users  will  have  flexibility  tochoosediffereni  building  blocks,  these 
building  blocks,  when  “compiled."  will  bring  users  to  a  common 
meeting  ground  with  ad  other  users  of  AXES. 

AXES  systems  can  be  hierarchically  decomposed  into  complete 
system  specifications  with  the  use  of  abstract  control  structures 
that  relate  members  of  algebraically  defined  data  types  Three 
primitive  control  structures  have  been  derived  from  six  axioms 
that  define  completeness  of  control  [  1  J  These  primitive  control 
structures  provide  rules  for  the  definition  of  communication. 
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parallel  processing,  and  selection  of  functions.  From  a  combina¬ 
tion  of  primitives,  we  can  form  more  abstract  control  structures 
(e.g.,  recursive  functions). 

The  syntax  of  AXES  [  4  ]  provides  the  mechanisms  to  specify 
control  structures  and  data  types.  The  purpose  of  AXES  is  to 
express  a  system  specification  which  is  equivalent  to  that  same 
specification  expressed  graphically  as  a  cmiirol  map.  Control 
structures  can  be  described  in  AXES  as  structures,  operations,  and 
functions.  Whereas  a  structure  is  a  relation  on  a  set  of  mappings, 
i.e.,  a  set  of  tuples  w'hose  members  are  sets  of  ordered  pairs,  an 
operation  is  a  set  of  mappings  which  stand  in  a  particular  relation. 
An  operation  results,  mathematically,  from  taking  particular 
mappings  as  the  arguments  (nodes)  of  a  structure  By  a  function, 
we  mean  a  set  of  mappings  which  stand  in  a  particular  relation  for 
which  particular  variables  have-  been  chosen  to  represent  their 
inputs  and  outputs.  Whereas  structures  and  operations  can  be 
described  as  purely  mathematical  constructs,  a  function  is  a 
hybrid,  consisting  of  a  mathematical  construct  and  a  linguistic 
construct,  i.e.,  an  assignment  of  particular  names  of  inputs  and 
outputs.  Note  that  our  use  of  “function"  is  slightly  different  from 
what  is  meant  by  "function"  in  mathematics.  For  the  latter  notion, 
we  use  the  term  “mapping"  throughout  this  paper. 

In  AXES,  a  new  data  type  can  be  defined  simply  in  terms  of  the 
operations  that  are  to  be  performed  on  the  data  [4].  That  is.  a 
data  type  is  defined  algebraically  rather  than  operationally  by- 
making  true  statements  (or  axioms)  about  the  equality  of  two 
control  structures  in  which  all  the  nodes  are  operations.  Each  such 
control  structure  is  defined  in  terms  of  primitive  operations  of  the 
data  type  of  interest  or  of  previously  characterized  primitive 
operations  of  another  type  (previously  characterized  primitive 
operations  include  universal  primitive  operations  that  have  been 
defined,  each  of  which  is  associated  with  any  member  of  any  data 
type). 

The  axioms  associated  with  the  definition  of  a  data  type  are  only 
those  we  need  to  characterize  the  data  type.  There  are.  of  course, 
other  operations  that  we  find  useful  for  other  purposes.  We  arc 
free  to  define  any  operation  we  want  on  an  already-defined  type  as 
long  as  the  operation  definition  is  consistent  with  ihc  axioms  of  the 
type.  A  new  operation  can  be  characterized  either  as  an  OPERA¬ 
TION  or  as  a  DERIVED  OPERA  TION. 

In  AXES,  we  specify  the  behavior  of  an  operation  without 
specifying  its  decomposition  by  writing  it  as  a  derived  operation, 
i.e.,  by  means  of  true  statements  that  describe  the  behavior  of  the 
operation  with  respect  to  other  already-defined  operations.  Either 
kind  of  operation  could  be  written  as  a  control  map,  if  desired. 
They  differ  in  how  they  are  specified,  not  in  what  they  are.  What 
distinguishes  both  of  these  kinds  of  operations  from  primitive 
operations  on  their  data  type  is  that  their  existence  is  provable 
mathematically  from  the  existence  of  the  primitive  operations  and 
the  axioms  of  the  type.  In  fact,  if  an  OPERA  TION  (which  defines 
a  function)  and  a  DERIVED  OPERATION  (which  defines  the 
behavior)  are  both  used  to  define  the  same  function,  the  behav¬ 
ioral  properties  can  be  checked  against  the  refinement  properties 
to  prove  the  correctness  of  a  definition. 

in  describing  AXES  we  wil]  use  variables  and  constants 
themselves  to  make  statements  about  the  values  they  name,  and  we 
w  ill  use  the  names  of  variables  mi?  constants  to  make  statements 
about  the  variables  and  constants  themselves. 

To  differentiate  an  object  from  its  name,  we  introduced  the 
"use-mention  distinction”  [  7  1  in  AXES  That  is.  we  can  talk 
about  an  object  only  by  using  a  name  of  the  object.  (To  talk  about 
a  man.  for  example,  we  have  to  use  a  sentence  that  contains  the 
man's  name,  not  the  man  himself.)  The  notation  conventionally 
used  for  this  is  enclosure  within  quotation  marks.  To  form  the 
name  of  a  given  name  (or  written  symbol  of  any  kind),  we  include 
thin  name  (or  symbol)  in  quotation  marks  (Succcssiv  *  embedding 
of  quotation  marks  can  be  used  if  we  want  to  talk  ab'ut  names, 
names  of  names,  and  names  of  names  of  names.) 

In  ANFS.  a  constant  symbol  is  the  name  of  a  particular  value 
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ar.d  corresponds  10  a  proper  noun  eke  "John.'  A  \ (triable  is  the 
name  of  xort  than  or.t  possible  sa'.ue  ar.J  corresponds  to  a 
coxmon  noun  iike  "a  ran." 


C'£=U'  i : 


Figure  All-1.  An  Example  of  Abstract-CootroFStrurlure 
Definition  Layers  with  Respect  to  AXES 

For  example,  in  Figure  AIJ-1.  the  top-most  box  is  a  description 
of  pa-t  of  AXES  itself.  The  top-most  box  describes  the  AXES 
objects  required  todefinea  STRL'CTL' RE'\n  AXES.  The  sentence 
STRL  CTL RE~  y  -=“  S  TO:’ 
xak.es  a  statement  about  values  by  using  the  v  aria  ole  “y'."s~.  and 
-x*  ar.d  about  constant  symbols  by  using  the  q'jjtation-marked 
symbols  such  as  “STRL  CTL  RE"",  and 

The  middle  box  encloses  an  AXES  object  itself;  that  ts.  the 
micdie  box  encloses  tne  ceitnilion  of  a  language  statement  derived 
from  the  definition  of  ar.  AXES  mocule.  Tne  Composition  (Cn) 
STRL  CTL  RE.  defined  .a  Figure  All- 1 .  is  one  of  the  th:.c  HOS 
primitive  control  structures.  Each  primitive  control  structure  has 
been  defined  as  a  STRL  CTL  RE  unit  AXES  [  4]*- 
The  middle  box  encloses  an  instance  of  the  layer  that  the 
topmost  box  represents.  If  me  could  describe  all  of  the  structures 
that  could  possibly  exist,  then  the  complete  set  of  structures  would 
be  the  layer  that  the  top-most  bo.x  describes. 

When  a  STRUCTURE  in  AXES  is  defined,  the  designer 
supplies  the  syntax  (or  description)  so  that  a  user  cf  that  structure 
can  describe  particular  mappings  that  stand  in  the  relation.  For 
example,  the  bottom-most  box  in  Figure  All-!  encloses  an  AXES 
object  that  is  an  instance  of  the  Cn  structure  described  in  the 
middle  box  of  Figure  Ail-1;  that  is.  the  boticm-xost  cox  is  ihe 
definition  of  a  system  derived  from  tne  definition  of  a  jnguagc 
statement,  derived  from  tne  definition  of  an  AXES  module.  In  the 
bottom-most  box.“b  =  Relatddl”  de>cr:oes  a  particular  function 
that  =  Cr.  igf  represents >n  the  x.cdle  box.  Likewise. 'd  “Su¬ 
per,  is-  '  ia..  represents  ar.  ir.>nar.:e  . :  "g  —  C n.i \ In  the 
n...;.:  rox.  the  object-  truit  ar.d  represent  are 

des.r.r.ed  ir.  t.'.e  statement 

liht'c  x.y.g  are  >•’ fimt  /..-••< 

Tr..s  siatexer.t  means  that  x,  y.  ar.d  g  are  var.abies  whose  values 
are  of  ar.  unspecified  data  type.  ir.  tne  bottom-most  box  the 
WHERE  statement  ts  used  to  specify  a  particular  data  type,  and 
the  operation.  Contact,  is  a  particuUr  mapping. 

Other  control  structures  can  be  der.ved  from  already  defined 
control  structures  and  operations  that  operate  on  variables  of  any 
type  Operations  'hat  operate  on  variables  of  ar.y  type  are  called 
unisersal  crc’tu  n\.  Primitive  universal  operations  are  defined  as 
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=  :  ■  ■  f>:htr'.L!e  y  =  firxi. 

.•'"(x.vi  a  ce\  Fa’i.'.u.n. 

Here,  the  .c : i  i-r .  r:rt  ir.c. cates  a  member  of  a  mem. re;  of  a  partition 
of  -x*. 

The  syntax  ter  ..ass  partir  :n  is 

y  “(Hi  fn. !uJt  =  f  ix.). 


x  =  Clonei  (x) 

(1) 

(x.x)  =  Clone;  (x) 

(2) 

con  =  Ktml(x) 

(3) 

X,  =  ldi(Xi.X;) 

(4) 

X:  =  idf(Xi.X;) 

(5) 

(Xi.X:)  =  Sl(x) 

(6) 

x  =  T(xi  ,X:) 

(7) 

( 1 )  and  (2)  are  used  to  specify  more  than  one  variable  with  the  same 
value.  (3)  is  used  to  choose  a  constant  symbol.  (4)  and  (5)  are  used 
to  select  the  value  of  one  of  a  set  of  variables.  (6)  and  (7)  are  related 
by  T(St(x))  =  x.  These  are  used  to  create  a  value  of  a  data  structure 
from  a  value  of  a  data  type  (i.e.,  St)  or  to  create  a  value  of  a  data 
type  from  a  value  of  data  structure  (i.e..  T). 

Universal  operations  have,  as  their  bottom  nodes,  universal 
primitive  operations.  Universal  operations  are  defined  as 
STRUCTURE  in  AXES  because  they  operate  on  values  which  are 
variables. 

We  can  now  define  a  structure  whose  syntax  can  be  used  to 
define  more  than  one  system  having  access  to  the  same  value. 
Here,  we  use  the  universal  operation 
y  =  id^(x) 

which  is  used  to  select  particular  variables  out  of  a  set  of  variables 
as  well  as  the  universal  primitive  operation 
(x.x)  =  Clone.-fx) 

to  determine  the  meaning  of  the  relationship  among  the  unspeci¬ 
fied  functions  that  appear  as  bottom  nodes  of  the  structure 
definition. 

STRUCTURE,  y  =  J(x), 

Where  y.g.w.h  are  of  some  type-. 

Where  b  is  a  NATURAL; 

Where  a  is  a  SET  (o/NATURALS); 
y  =  Ji(g.w)  Join  (g.vv)  =  J:(x); 

(g.w)  =  J,;(x.x)  Join  (x.x)  =  Clone.-(x); 

g  =  Jii:(x)  Include  w  id.(x); 

g  =  Ji,,;(h)  Join  h  =  idc(xh 

SYS'TAX:  v  =  Ji(g.w)  Cotton  g  =  Jin:(h); 

E\  D  J; 

In  using  the  syntax  of  a  structure,  an  instance  of  the  layer  of  the 
structure  definition  can  be  obtained.  In  the  Cojoin  structure,  there 
are  actually  four  unspecified  mappings  besides  the  top  node:  Ji. 
J , , , .  .  id.\  id'.  But  in  the  use  of  the  Cojoin,  the  value  of  “w“  and  “x" 
uniquely  determines  the  particular  id,'  function.  Likewise,  the 
value  of  ”h”  and  “x”  uniquely  determines  the  particular  id'.  Thus, 
only  J,.  J,,..  need  appear  in  the  syntax  of  the  Cojoin  definition 

The  collective  set  of  values  that  replaces  the  variables  described  in 
the  syntax  can  be  traced  to  each  node  of  the  structure  definition. 
For  example,  if 

(a.b)  =  F(r,t.s) 
is  defined  as 

(a.b)  =  A(p.q.r)  Cojoin  (p.q)  =  B(r.t) 

The  first  and  second  statement  collectively  form  an  instance  of  the 
Cojoin  structure. 

In  this  example, 

“x"  has  the  value  “(r.t.s)” 

“J"  has  the  value  “A” 

"v"  has  the  value  “(a.b)" 

“g"  has  the  value  “(p.q)" 
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“w"  has  the  value  “r“ 

“Jin;  "  has  the  value  “B" 

and.  since  the  input  to  F  has  three  components.  “b"  in  the  structure 
definition  has  the  value  “3”,  since  “w”  has  the  value  “r".  w  hich  has 
one  component,  “a"  in  the  structure  definition  has  the  value  T. 
and  so  on.  The  structure  syntax  names  the  objects  necessary  so 
that  an  instance  of  the  structure  definition  is  obtained.  Any 
instance  of  a  structure  must  itself  be  an  HOS  system. 

In  the  Cojoin  structure,  systems  that  communicate  with  each 
other  can  access  the  same  value.  Likewise,  we  define  other 
structures;  one  so  that  independent  subfunctions  can  access  the 
same  value  (the  Coinclude),  and  one  so  that  subfunctions  whose 
invocation  depends  on  the  value  of  the  controller’s  input  set  need 
not  access  the  entire  set  of  variables  of  the  input  set  (the  Coeither) 

f  5] 

If  the  controller’s  function  is  y  =  F(x)  and  y  =  (yi.y:); 

g  =  id  J(x); 
h  =  id?(x); 

then 

SYSTAX:  y,  =  A(g)  Coinclude  v-  =  B(h); 

SYXTAX:  y  =  A(g)  Coeither  y  =  B(h); 

Structures,  in  addition  to  the  primitive  control  structures,  e.g., 
Cojoin\  can  be  used  to  define  other  structures.  For  example,  the 
Whereby,  defined  with  the  Cojoin,  gives  us  the  facility  to  use 
constant  symbols  as  operands  of  a  function. 

SYXTAX:  Whereby  y  =  W(h.CON): 

The  Whereby  is  used  as  in 

>■  =  *+! 

Here,  the  constant  symbol  "l"  defines  the  particular  Kto, 
operation  that  makes  the  instance  of  the  Whereby  structure  a 
function.  Note  also  that  the  operator  “+“  (an  instance  of  W)  is  used 
as  an  infix  operator.  In  AXES  we  are  free  to  use  either  prefix  or 
infix  notation,  as  desired. 

We  can  visualize  the  instance  of  a  structure  as  being  either 
written  dow  n  on  a  piece  of  paper  by  a  human  being,  or  to  a  register 
by  a  software  or  hardware  process.  To  check  an  instance  in  an 
HOS  system,  the  use  of  a  STRUCTURE  is  compared  with  the 
STRUCTURE  definition  itself  by  an  analyzer.  All  instances  of  a 
structure  can  be  viewed  as  being  supplied  to  the  structure 
dynamically.  The  STRUCTURE  for  an  asynchronous  system, 
such  as  an  operating  stem  or  the  Higher  Order  Machine (HOM) 
[33].  is  a  recur  r  e  ;.  ..-•.'.ion  relating  each  state  of  a  machine  to  a 
previous  state  of  tnc  same  machine  within  an  instance  of  a  machine 
system.  To  check  the  instances  of  an  asynchronous  machine  in  a 
real-time  environment,  an  analyzer  is  used  to  check  not  only  the 
use  of  the  STRUCTURE  with  the  STRUCTURE  definition, 
itself,  also  to  check  to  see  that  all  the  users  of  that  STRUCTURE 
are  consistent. 

We  indicate  the  potential  happening  of  each  machine  instance 
by  specifying  a  user  system  to  be  "On"  the  machine  system,  e  g., 
the  syntax  Where  A  on  HOM  specifies  the  initial  nodal  family  of 
system  A  to  be  used  by  the  first  machine  instance  and  the  nodal 
family  for  each  next  recursive  instance  of  the  HOM  function  K,  to 
be  determined  by  the  ordering  relationships  of  the  nodal  families 
within  system  A.  A  nodal  family  is  a  3-tuple  w  hose  members  are 
functions  which  stand  in  a  particular  relation  (c.f.  Appendix  I).  By 
indicating  only  “HOM"  in  the  syntax  of  this  structure,  rather  than, 
for  example  "y  =  HOM(x)."  the  state  of  the  HOM  remains  hidden 
from  the  user. 

II.  Levels  and  Layers  in  AXES 

In  AXES  we  emphasize  in  our  notation  the  separation  of  the 
layers  within  one  system  or  between  systems.  The  layer  relation¬ 


ships  are  defined  with  the  Where  statement  in  AXES. 

In  particular,  we  distinguish  between  in  instance  of  a  layer 
(representing  one  performance  pass  of  a  system)*  and  a  layer 
(representing  all  performance  passes  of  a  system).  We  distinguish 
between  communication  within  one  layer,  which  always  repre¬ 
sents  the  same  instance,  and  communication  between  layers. 
which  takes  place  when  an  instance  of  one  layer  communicates 
with  an  instance  of  another  layer  (e.g..  real-time  asynchronous 
processes).  We  distinguish  between  (I)  the  system  and  the 
definition  of  that  system,  (2)  the  system  and  the  description  of  that 
system,  (3)  the  system  and  the  implementation  of  that  system,  and 
(4)  the  system  and  the  execution  of  that  system. 

A  machine  is  a  system  which  executes  another  system.  There  are 
dedicated  machines,  asynchronous  machines,  and  asynchronous 
machines.  A  dedicated  machine  always  performs  the  same  func¬ 
tion.  Thus  the  “mapping"  of  an  AXES  FUSCTION  could  be 
viewed  as  a  dedicated  machine.  A  synchronous  machine  must  only- 
execute  one  system  to  completion  before  another  system  uses  that 
machine.  An  AXES  OPERA  TIOS  could  be  viewed  as  a  synchro¬ 
nous  machine.  An  asynchronous  machine  may  execute  instances 
of  more  than  one  system  before  either  system  reaches  execution 
completion.  Thus,  an  AXES  STRUCTURE  can  be  viewed  as  an 
asynchronous  machine. 

The  environment  of  a  machine  must  be  secure  in  that  (1)  a  user 
should  not  have  to  be  concerned  with  any  of  the  details  that  have 
to  do  with  its  execution,  and  (2)  a  user  should  not  be  allowed  to 
have  visibility  into  another  user's  environment. 

In  an  asynchronous  machine  there  are  several  types  of  data,  all 
of  which  must  be  maintained  as  secure  data  throughout  all 
instances  of  the  machine.  These  types  of  data  include  (I) 
temporary  values  which  exist  for  one  or  more  users.  (2)  values 
from  another  machine  with  respect  to  the  machine  itself  as  a  user. 
(3)  values  with  respect  to  the  variables  of  the  machine  itself,  (4) 
values  which  are  functionally  related  to  a  previous  instanceof  the 
machine  system.  (5)  values  which  are  functionally  related  to  a 
previous  instance  of  the  machine  for  a  given  instance  of  a  user, 
and  (6)  values  which  are  functionally  related  to  a  previous  in¬ 
stance  of  the  machine  for  a  given  instance  of  another  machine. 

The  definition  (dynamic  state)  of  a  system  is  equivalent  to  the 
formal  semantics  of  a  system.  The  description  (static  state)  of  a 
system  is  equivalent  to  the  syntax  of  a  system.  The  implementa¬ 
tion  (static  state  which  includes  a  system,  a  machine  to  run  that 
system,  and  the  mechanisms  necessary  to  relate  that  system  to 
the  machine)  of  a  system  is  equivalent  to  that  same  system  ready 
to  be  exercised.  The  execution  (dynamic  state  which  includes  a 
system,  a  machine  running  that  system,  and  mechanisms  which 
relate  that  system  to  the  machine)  of  a  system  is  that  system  being 
exercised  by  a  machine. 

Not  only  must  we  be  aware  of  the  types  of  system  layers,  but 
we  also  must  be  aware  of  how  many  different  definitions,  des¬ 
criptions,  implementations,  and  executions  are  possible  or  po¬ 
tentially  possible  for  one  system.  Most  important,  we  must  deter¬ 
mine  those  states  which  are  necessary  and  those  which  are  not 
only  unnecessary  but  which  are  causing  serious  difficulties  in  the 
development  of  a  system.  Towards  this  end  it  is  necessary  to  have 
available  a  means  for  determining  both  the  types  and  the  nature 
and  number  of  states  within  each  type  [5  ] 

Sometimes  the  need  for  the  definition  of  the  layers  of  a  system 
depends  on  how  the  system  is  to  be  developed  and  executed.  On 
one  project  the  users  might  wish  to  compile  source  code  before  a 
target  system  is  ready  to  be  executed.  On  another  project  users 
might  wish  to  interpret  the  code  in  real  time.  Thus,  not  only  must 
the  layers  of  a  system  be  determined,  but  also  it  must  be  deter¬ 
mined  when,  how,  and  where  transformations  from  one  layer  to 
another  layer  take  place. 


•as  opposed  lo  a  level  which  is  a  step  of  refinement  (or  more  explicit 
definition)  within  a  given  instance  of  a  layer. 
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In  the  resour:;  allocation  process,  a  name  is  assigned  to  a  value 
or  a  value  to  a  name.  Resource  allocation  also  includes  the  ability 
to  replace  a  name  by  an  equivalent  name  or  a  value  by  an 
equivalent  value.  Sometimes  one  layer  is  produced  from  another 
laser  by  a  third  layer.  Sometimes  the  description  of  a  layer,  as 
opposed  to  the  layer  itself,  becomes  the  object  of  communication. 
Sometimes  the  same  layer  is  resource  allocated  as  a  function  to  one 
layer  and  as  data  to  another  layer. 

The  general  concepts  of  layer  communication  can  be  related  to 
familiar  examples.  When  two  asynchronous  processes  are  in  the 
execution  mode,  a  value  from  a  given  process  is  assigned  to  a  name 
(or  variable)  associated  with  another  process.  Conversely,  that 
other  process  assigns  a  value  to  the  name  associated  with  the  first 
process.  W'hen  ar.  integer  is  implemented,  a  specific  representation 
tor  valuel  for  a  specific  machine  is  assigned  to  the  name 
representing  the  integer.  When  a  compiler  compiles  an  HOL 
program,  it  assigns  names  (or  registers)  to  values  in  order  to 
translate  from  one  description  to  another.  It  also  fulfills  an 
implementation  function  in  that  operations  and  data  are  replaced 
with  specific  machine-dependent  values.  A  compiler,  in  order  to 
operate  on  an  HOL  program,  must  be  able  to  read  the  description 
layer  of  the  program  as  input  for  the  translation  process.  In 
addition,  it  requires  further  input  of  its  ow  n  in  order  to  provide  the 
implementation  layer  of  the  program.  An  OS  system  has  a  more 
complex  job  in  that  it  is  usually  required  to  communicate  with 
both  the  description  of  a  system  and  the  system  itself.  When  a 
function  is  refined  to  a  lower  level  of  more  detailed  functions,  the 
control  integrity  of  the  values  and  names  from  the  parent  layer 
must  be  maintained  at  the  layer  of  the  offspring. 

Ideally,  we  want  to  be  able  to  define  a  system,  as  abstractly  as 
possible;  describe  t.-.at  system  in  a  syntax  we  can  all  relate  to;  verify 
that  description;  implement  that  system  for  a  machine  that  will 
talk  directly  to  that  system;  and  collect  the  machine  mechanisms, 
and  only  those  mechanisms,  that  are  necessary  to  execute  a  given 
system.  In  such  a  wav  we  can  eliminate  dependencies  on  a 
particular  primitive  machine  until  the  scry  end  of  a  development 
process.  For  when  we  go  from  one  definition  loanothei;  from  one 
description  to  another,  from  one  implementation  to  another,  or 
from  one  execution  to  another,  we  are  really  resource  allocating  to 
another  machine  level.  Thus,  there  should  be  no  need  to  resource 
allocate  for  more  than  one  given  layer  at  a  time. 
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